[issue38588] Use-after-free in dict/list

[LCatro]

LCatro  added the comment:

Sure ,but how can i pull my fix code ?

--

___
Python tracker 

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

[issue38610] use-after-free in list object function

[LCatro]

New submission from LCatro :

Code 1 :

static PyObject *
list_index_impl(PyListObject *self, PyObject *value, Py_ssize_t start,
Py_ssize_t stop)
// ...
for (i = start; i < stop && i < Py_SIZE(self); i++) {
int cmp = PyObject_RichCompareBool(self->ob_item[i], value, Py_EQ);  <= 
 self->ob_item[i] can uaf ..


PoC :

class rewrite_list_eq(list) :
def __eq__(self,other) :
str(other)   #  <== that will call the object recall function tp_repr 
and call it ..
return NotImplemented

class poc() :
def __eq__(self,other) :
list1.clear()
return NotImplemented

list1 = [ poc() ]
list1.index(list1)   #  list_index_impl() -> PyObject_RichCompareBool()


Crash Report :

(gdb) run ../py_poc/list_poc_3.py
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tangjitao/Python-3.8.0/python ../py_poc/list_poc_3.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
PyObject_Str (v=0x76e82d20) at Objects/object.c:573
573 if (Py_TYPE(v)->tp_str == NULL)

= 

Code 2 :

static PyObject *
list_count(PyListObject *self, PyObject *value)
{
Py_ssize_t count = 0;
Py_ssize_t i;

for (i = 0; i < Py_SIZE(self); i++) {
int cmp = PyObject_RichCompareBool(self->ob_item[i], value, Py_EQ);  // 
 <=


PoC :

class rewrite_list_eq(list) :
def __eq__(self,other) :
str(other)
return NotImplemented

class poc() :
def __eq__(self,other) :
list1.clear()
return NotImplemented

list1 = rewrite_list_eq([ poc() ])
list1.count(list1)   #  list_count() -> PyObject_RichCompareBool()


Crash Report :

(gdb) run ../py_poc/list_poc_4.py
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tangjitao/Python-3.8.0/python ../py_poc/list_poc_4.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
PyObject_Str (v=0x76e82d20) at Objects/object.c:573
573 if (Py_TYPE(v)->tp_str == NULL)


===

Code 3 :

static PyObject *
list_remove(PyListObject *self, PyObject *value)
/*[clinic end generated code: output=f087e1951a5e30d1 input=2dc2ba5bb2fb1f82]*/
{
Py_ssize_t i;

for (i = 0; i < Py_SIZE(self); i++) {
Py_INCREF(self->ob_item[i]);
int cmp = PyObject_RichCompareBool(self->ob_item[i], value, Py_EQ);


PoC :

class rewrite_list_eq(list) :
def __eq__(self,other) :
str(other)
return NotImplemented

class poc() :
def __eq__(self,other) :
list1.clear()
return NotImplemented

list1 = rewrite_list_eq([ poc() ])
list1.remove(list1)   #  list_count() -> PyObject_RichCompareBool()


Crash Report :

(gdb) run ../py_poc/list_poc_5.py
Starting program: /tangjitao/Python-3.8.0/python ../py_poc/list_poc_5.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
PyObject_Str (v=0x76e82d20) at Objects/object.c:573
573 if (Py_TYPE(v)->tp_str == NULL)

--
components: Interpreter Core
messages: 355513
nosy: LCatro, serhiy.storchaka
priority: normal
severity: normal
status: open
title: use-after-free in list object function
type: crash
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

[issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)

[Dong-hee Na]

Dong-hee Na  added the comment:

On issue 38602, the constant related to open file descriptors will be added.
I will finalize this issue after issue 38602 is closed.

--
assignee:  -> corona10
nosy: +corona10

___
Python tracker 

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

[issue38602] Add fcntl.F_OFD_XXXX constant

[Dong-hee Na]

Dong-hee Na  added the comment:

> See also issue22367.

Okay I will take a look at it also. :)

--

___
Python tracker 

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

[issue38609] Trashcan mechanism segfault during interpreter finalization in Python 3.7.5

[ysnt27]

New submission from ysnt27 :

My original issue was reported to Boost.Python,
https://github.com/boostorg/python/issues/248
And I found similar issue
https://bugs.python.org/issue17703

It seems root cause exists in Python not Boost.Python.
As the issue #17703 is already closed, I want to open a new issue.

I attached a sample source code, "sample1.cc".
With the code, I can reproduce segmantation fault, like this.

% gdb /usr/local/python375/bin/python3.7dm
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/python375/bin/python3.7dm...done.
(gdb) run
Starting program: /usr/local/python375/bin/python3.7dm 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Python 3.7.5 (default, Oct 25 2019, 16:11:10) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sample1
something called
>>> sample1.dummy()
[1]
>>> exit()
~something called

Program received signal SIGSEGV, Segmentation fault.
0x0044602a in list_dealloc (op=op@entry=0x77f4b360)
at ../Objects/listobject.c:316
316 Py_TRASHCAN_SAFE_BEGIN(op)
(gdb) p _PyRuntime.gilstate.tstate_current
$1 = {_value = 0}
(gdb) where
#0  0x0044602a in list_dealloc (op=op@entry=0x77f4b360)
at ../Objects/listobject.c:316
#1  0x00466452 in _Py_Dealloc (op=0x77f4b360)
at ../Objects/object.c:1971
#2  0x7051cc28 in something::~something (this=0x7071e140 , 
__in_chrg=) at sample1.cc:26
#3  0x76eeac99 in __run_exit_handlers (status=status@entry=0, 
listp=0x772786c8 <__exit_funcs>, 
run_list_atexit=run_list_atexit@entry=true) at exit.c:77
#4  0x76eeace7 in __GI_exit (status=status@entry=0) at exit.c:99
#5  0x005178e4 in Py_Exit (sts=sts@entry=0)
at ../Python/pylifecycle.c:2292
#6  0x0051faf4 in handle_system_exit () at ../Python/pythonrun.c:636
#7  0x00520d88 in PyErr_PrintEx (
set_sys_last_vars=set_sys_last_vars@entry=1) at ../Python/pythonrun.c:646
#8  0x0052115f in PyErr_Print () at ../Python/pythonrun.c:542
#9  0x00521d1a in PyRun_InteractiveLoopFlags (
fp=fp@entry=0x77279640 <_IO_2_1_stdin_>, 
filename_str=filename_str@entry=0x5e55b2 "", 
flags=flags@entry=0x7fffe2f0) at ../Python/pythonrun.c:134
#10 0x005223d8 in PyRun_AnyFileExFlags (
fp=fp@entry=0x77279640 <_IO_2_1_stdin_>, filename=0x5e55b2 "", 
closeit=closeit@entry=0, flags=flags@entry=0x7fffe2f0)
---Type  to continue, or q  to quit---
at ../Python/pythonrun.c:78
#11 0x00422023 in pymain_run_file (fp=0x77279640 <_IO_2_1_stdin_>, 
filename=0x0, p_cf=p_cf@entry=0x7fffe2f0) at ../Modules/main.c:427
#12 0x004220e5 in pymain_run_filename (
pymain=pymain@entry=0x7fffe320, cf=cf@entry=0x7fffe2f0)
at ../Modules/main.c:1606
#13 0x004221d8 in pymain_run_python (pymain=pymain@entry=0x7fffe320)
at ../Modules/main.c:2867
#14 0x0042550f in pymain_main (pymain=pymain@entry=0x7fffe320)
at ../Modules/main.c:3028
#15 0x00425589 in _Py_UnixMain (argc=, 
argv=) at ../Modules/main.c:3063
#16 0x0041f116 in main (argc=, argv=)
at ../Programs/python.c:15
(gdb) l
311 static void
312 list_dealloc(PyListObject *op)
313 {
314 Py_ssize_t i;
315 PyObject_GC_UnTrack(op);
316 Py_TRASHCAN_SAFE_BEGIN(op)
317 if (op->ob_item != NULL) {
318 /* Do it backwards, for Christian Tismer.
319There's a simple test case where somehow this reduces
320thrashing when a *very* large list is created and
(gdb)

--
components: Interpreter Core
files: sample1.cc
messages: 355510
nosy: ysnt27
priority: normal
severity: normal
status: open
title: Trashcan mechanism segfault during interpreter finalization in Python 
3.7.5
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48681/sample1.cc

___
Python tracker 

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

[issue23692] Undocumented feature prevents re module from finding certain matches

[Ma Lin]

Change by Ma Lin :


--
nosy: +Ma Lin

___
Python tracker 

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

[issue38608] Undocumented behavior that IsolatedAsyncioTestCase would enable event loop debug mode

[Wei-Cheng Pan]

New submission from Wei-Cheng Pan :

In bpo-32972 we enabled debug mode in 
IsolatedAsyncioTestCase._setupAsyncioLoop, which may print some warnings that 
are not that important to tests.
(e.g. Executing  took 0.110 seconds)

I personally don't really like it being turn on by default, but if it needs to 
be so, maybe include it in document would be a good idea.

Add Andrew to nosy list because he was the author.

--
components: Tests
messages: 355509
nosy: asvetlov, legnaleurc
priority: normal
severity: normal
status: open
title: Undocumented behavior that IsolatedAsyncioTestCase would enable event 
loop debug mode
type: behavior
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

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

Andrew Svetlov  added the comment:

At least it is my learned lesson from aiohttp development.

--

___
Python tracker 

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

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I have a different feeling: we should start raising deprecation for 
asyncio.Queue() if it is created without running event loop.

It required `get_event_loop()` and `loop.is_running()` checks.

Later the pair can be replaced with `get_running_loop()`.

I think no check at awaiting time is needed; we never do it for other asyncio 
parts.  Just control of the loop at creation time is enough; if the object is 
created inside a running loop the sane code will use it with this loop context 
always.

--

___
Python tracker 

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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

[Guido van Rossum]

Guido van Rossum  added the comment:

We never should have mentioned 4.0 as the target date to make this the
default (and only) behavior -- who knows whether there will ever even be a
Python 4.0? Even 3.10 might be on the early side (assuming we'll switch to
a year-long release cycle per PEP 602 -- we will then make deprecations in
general take two release cycles).

I do agree that we should start the process of deprecating the
non-__future__ behavior here in 3.9. I know of one project with a private
fork of Python (for other reasons) that has made this default.

--

___
Python tracker 

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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Also, next time I suggest that you try running the code at least once before 
submitting it, as your code contains a syntax error that prevents it from 
running.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue38602] Add fcntl.F_OFD_XXXX constant

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See also issue22367.

--

___
Python tracker 

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

[issue38530] Offer suggestions on AttributeError

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Interesting, why locals are not cleared when an exception leaves a frame?

--

___
Python tracker 

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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

Actually there is a patch. So please @netbnd please open a PR 
https://github.com/python/cpython

--

___
Python tracker 

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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

@benedwards14 Feel free to open a PR. @netbnd said anyone can take on the issue 
since he may take long to revert with a PR.

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue21002] _sre.SRE_Scanner object should have a fullmatch() method

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I concur with David. The SRE_Scanner object is not public. Its search() method 
is used for implementing finditer(). Its match() method could be useful for 
implementing a functional equivalent of \G in Perl. But I do not know a use 
case for its fullmatch() method.

If anybody provide a use case for SRE_Scanner.fullmatch() this issue can be 
reopened.

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

___
Python tracker 

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

[issue38530] Offer suggestions on AttributeError

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think I am going to proceed to modify PR 16856 by adding the name and the 
object to the AttributeError exceptions.

This should not extend the lifetime of the object more than the current 
exception is doing as the exception keeps alive the whole frame stack in the 
__traceback__ attribute. Consider this code for example:

class Target:
def __del__(self):
print("The object is dead!")

def f():
g()

def g():
h()

def h():
theobj = Target()
theobj.thevalue

try:
f()
except Exception as e:
print(e.__traceback__.tb_next.tb_next.tb_next.tb_frame.f_locals["theobj"])
print("End of except")
print("Begining of the next line")


This code prints:

<__main__.Target object at 0x7f064adbfe10>
End of except
The object is dead!
Beginning of the next line

We can notice two things:
   * The target objects are reachable from the exception.
   * When the exception dies, the target object dies.

Adding another reference to the target object to the exception won't change the 
current lifetime, neither will create reference cycles as the target object 
will not have (unless explicitly created) a reference to the exception. We can 
conclude that this change should be safe.

In the resolution email for PEP473 the council stated that "Discussions about 
adding more attributes to built-in exceptions can continue on the issue tracker 
on a per-exception basis". As I think this will be very beneficial for the 
feature discussed in the issue, I will proceed as indicated.

Notice that if we want to change all internal CPython code that raises 
AttributeError to use the new fields, this should be done in a different PR to 
keep this minimal. For this feature, we still need to intercept AttributeError 
raised by the user without these fields added.

--

___
Python tracker 

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

[issue38530] Offer suggestions on AttributeError

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think I am going to proceed modifying PR 16858 by adding the name and the 
object to the AttributeError exceptions.

This should not extend the lifetime of the object more than the current 
exception is doing as the exception keeps alive the whole frame stack in the 
__traceback__ attribute. Consider this code for example:

class Target:
def __del__(self):
print("The object is dead!")

def f():
g()

def g():
h()

def h():
theobj = Target()
theobj.thevalue

try:
f()
except Exception as e:
print(e.__traceback__.tb_next.tb_next.tb_next.tb_frame.f_locals["theobj"])
print("End of except")
print("Begining of the next line")


This code prints:

<__main__.Target object at 0x7f064adbfe10>
End of except
The object is dead!
Beginning of the next line

We can notice two things:
   * The target objects are reachable from the exception.
   * When the exception dies, the target object dies.

Adding another reference to the target object to the exception won't change the 
current lifetime, neither will create reference cycles as the target object 
will not have (unless explicitly created) a reference to the exception. We can 
conclude that this change should be safe.

In the resolution email for PEP473 the council stated that "Discussions about 
adding more attributes to built-in exceptions can continue on the issue tracker 
on a per-exception basis". As I think this will be very beneficial for the 
feature discussed in the issue, I will proceed as indicated.

Notice that if we want to change all internal CPython code that raises 
AttributeError to use the new fields, this should be done in a different PR to 
keep this minimal. For this feature, we still need to intercept AttributeError 
raised by the user without these fields added.

--

___
Python tracker 

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

[issue38530] Offer suggestions on AttributeError

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

lgtm

--

___
Python tracker 

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

[issue38529] Python 3.8 improperly warns about closing properly closed streams

[Yury Selivanov]

Yury Selivanov  added the comment:

Yes, I've experienced this bug. We need to fix this in 3.8.1.

--
nosy: +lukasz.langa
priority: normal -> release blocker

___
Python tracker 

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

[issue38314] Implement unix read_pipe.is_reading() method

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Please do.

--

___
Python tracker 

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

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Yury Selivanov]

Yury Selivanov  added the comment:

Yes.

As a remedy for this particular problem we can add checks here and there 
comparing `asyncio.get_running_loop()` and `self._loop`.  Performance will 
suffer a bit but the usability will greatly improve.

--

___
Python tracker 

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Kyle Stanley]

Kyle Stanley  added the comment:

> Regarding 3.8 release notes update -- not sure if it is needed flr docs-only 
> change.

I'm not certain if the entry is necessary; my main concern is just that it's 
already present in the 3.8 release notes/whatsnew without anywhere to look for 
further information. 

> In the current situation, we have so-called *soft deprecation*: bare 
> coroutines are deprecated in docs without any code change. This is perfectly 
> fine, we give our users extra time to prepare for changes.

So is something considered to be a "soft deprecation" if there is no code 
change? If so, I may have made a mistake by specifying a release in the entry I 
recently added for it (https://docs.python.org/3/whatsnew/3.8.html#deprecated):

"The explicit passing of coroutine objects to asyncio.wait() has been 
deprecated and will be removed in version 3.10."

I would propose to adjust this to:

"The explicit passing of coroutine objects to asyncio.wait() has been 
deprecated. (Contributed by Yury Selivanov in :issue:`34790`.)"

Then for 3.9 whatsnew, we could specify the release:

"The explicit passing of coroutine objects to asyncio.wait() has been 
deprecated and will be removed in 3.11."

Thoughts?

--

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[ishan gambhir]

Change by ishan gambhir :


--
components: +Library (Lib)

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[ishan gambhir]

Change by ishan gambhir :


--
status: open -> closed

___
Python tracker 

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Kyle Stanley]

Kyle Stanley  added the comment:

Sounds good, I'll work on opening a PR.

--

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[ishan gambhir]

ishan gambhir  added the comment:

no issue I will consider your worthy sugestion

--
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Yury Selivanov]

Yury Selivanov  added the comment:

I'd add `and will be removed in 3.11.` now.

--

___
Python tracker 

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

[issue38607] Document that cprofile/profile only profile the main thread

[Ben Spiller]

New submission from Ben Spiller :

The built-in profiling modules only provide information about the main thread 
(at least when invoked as documented). 

To avoid user confusion we should state this in the documentation at 
https://docs.python.org/3/library/profile.html. 

Potentially we could also suggest mitigations such as manually creating a 
Profile instance in the user's thread code, but the most important thing is to 
make clear what the module does/does not do out of the box. 

(see also https://bugs.python.org/issue9609 which discusses a possible non-doc 
change to help with multi-threading, but looks like that's stalled, so best to 
push ahead with doc'ng this.

--
assignee: docs@python
components: Documentation
messages: 355492
nosy: benspiller, docs@python
priority: normal
severity: normal
status: open
title: Document that cprofile/profile only profile the main thread
type: enhancement
versions: 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

[issue38606] Function to count total number of common divisors of two numbers

[Mark Dickinson]

Mark Dickinson  added the comment:

Sorry, but I'm rejecting this: I don't think this is likely to have value to a 
range of users, and it's not a basic building block - as such, it doesn't 
really fit with the current design and intended usage of the math module.

You might consider publishing your code and recipes in a PyPI package: if that 
package gets a lot of users, that could be motivation to consider adding its 
functionality to core Python.

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

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[ishan gambhir]

Change by ishan gambhir :


--
components:  -2to3 (2.x to 3.x conversion tool)

___
Python tracker 

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

[issue21002] _sre.SRE_Scanner object should have a fullmatch() method

[Kyle Stanley]

Kyle Stanley  added the comment:

> Is anyone able to make a call on whether this issue should be closed, or 
> alternatively give some guidance on what work this issue should encompass?

Added Serhiy to the nosy list, since he's an active maintainer for the re 
module.

--
nosy: +aeros

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[ishan gambhir]

New submission from ishan gambhir :

The function given in attached file can be added in math module

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 355490
nosy: ishan gambhir
priority: normal
severity: normal
status: open
title: Function to count total number of common divisors of two numbers
type: enhancement
Added file: https://bugs.python.org/file48680/cd_count.py

___
Python tracker 

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

[issue21002] _sre.SRE_Scanner object should have a fullmatch() method

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue23692] Undocumented feature prevents re module from finding certain matches

[Matthew Barnett]

Matthew Barnett  added the comment:

Suppose you had a pattern:

.*

It would advance one character on each iteration of the * until the . failed to 
match. The text is finite, so it would stop matching eventually.

Now suppose you had a pattern:

(?:)*

On each iteration of the * it wouldn't advance, so it would keep matching 
forever.

A way to avoid that is to stop the * if it hasn't advanced.

The example pattern shows that there's still a problem. It advances if a group 
has matched, but that group doens't match until the first iteration, after the 
test, and does not, itself, advance. The * stops because it hasn't advanced, 
but, in this instance, that doesn't mean it never will.

The solution is for the * to check not only whether it has advanced, but also 
whether a group has changed. (Strictly speaking, the latter check is needed 
only if the repeated part tests whether a group also in the repeated part has 
changed, but it's probably not worth "optimising" for that possibility.)

In the regex module, it increments a "capture changed" counter whenever any 
group is changed (a group's first match or a change to a group's span). That 
makes it easier for the * to check. The code needs to save that counter for 
backtracking and restore it when backtracking.

I've mentioned only the *, but the same remarks apply to + and {...}, except 
that the {...} should keep repeating until it has reached its prescribed 
minimum.

--

___
Python tracker 

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

[issue38606] Function to count total number of common divisors of two numbers

[Mark Dickinson]

Mark Dickinson  added the comment:

Thank you for the suggestion. I don't think this fits that well with the view 
of the math module as a set of basic building blocks: this is quite a 
specialist function that wouldn't come up often in applications.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

[Ivan Levkivskyi]

Ivan Levkivskyi  added the comment:

IMO 3.10 would be better, since 3.9 would be too soon (it would be like a 
schedule for a normal deprecation).

Also if we are really doing this, I think it is better to announce this soon.

Also we should try to fix relevant issues related to string annotations (in 
typing and dataclasses), like https://github.com/python/typing/issues/508, 
https://github.com/python/typing/issues/574, 
https://bugs.python.org/issue37838, https://bugs.python.org/issue34776 and 
https://bugs.python.org/issue37948.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue38529] Python 3.8 improperly warns about closing properly closed streams

[Ron Frederick]

Ron Frederick  added the comment:

Sorry, I should have said that the change below was in the file 
asyncio/streams.py.

--

___
Python tracker 

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

[issue38529] Python 3.8 improperly warns about closing properly closed streams

[Ron Frederick]

Ron Frederick  added the comment:

I think the following change might address this problem:

***
*** 233,239 
  
  def _on_reader_gc(self, wr):
  transport = self._transport
! if transport is not None:
  # connection_made was called
  context = {
  'message': ('An open stream object is being garbage '
--- 233,239 
  
  def _on_reader_gc(self, wr):
  transport = self._transport
! if transport is not None and not transport.is_closing():
  # connection_made was called
  context = {
  'message': ('An open stream object is being garbage '

--

___
Python tracker 

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

[issue32354] Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICODE_TOUPPER

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-38604: Schedule Py_UNICODE API removal.

--

___
Python tracker 

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

[issue37330] open(): remove 'U' mode, deprecated since Python 3.3

[STINNER Victor]

STINNER Victor  added the comment:

I cited this change in the PEP 608 "Coordinated Python release".

--

___
Python tracker 

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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +levkivskyi

___
Python tracker 

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

[issue38604] Schedule Py_UNICODE API removal

[STINNER Victor]

STINNER Victor  added the comment:

> (Right now) write an exhaustive list of all deprecated APIs: functions, 
> constants, types, etc.

I searched "4.0" in the documentation:

* Py_UNICODE type
* array.array: "u" type
* PyArg_ParseTuple, Py_BuildValue: "u", "u#", "Z", "Z#" formats

* PyUnicode_FromUnicode()
* PyUnicode_GetSize(), PyUnicode_GET_SIZE()
* PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_AS_DATA()
* PyUnicode_AsUnicodeAndSize()
* PyUnicode_AsUnicodeCopy()

* PyUnicode_FromObject()
* PyLong_FromUnicode()
* PyUnicode_TransformDecimalToASCII()

* PyUnicode_Encode()
* PyUnicode_EncodeUTF7()
* PyUnicode_EncodeUTF8()
* PyUnicode_EncodeUTF32()
* PyUnicode_EncodeUTF16()
* PyUnicode_EncodeUnicodeEscape()
* PyUnicode_EncodeRawUnicodeEscape()
* PyUnicode_EncodeLatin1()
* PyUnicode_EncodeASCII()
* PyUnicode_EncodeMBCS()
* PyUnicode_EncodeCharmap()
* PyUnicode_TranslateCharmap()

--

___
Python tracker 

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

[issue37838] typing.get_type_hints not working with forward-declaration and decorated functions

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Hey Netzeband, are you still working on this, or would it be ok for me to have 
a go? 

If all you needed was help with a PR let me know, i have some experience?

--
nosy: +benedwards14

___
Python tracker 

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

[issue38605] [typing] PEP 563: Postponed evaluation of annotations: enable it by default before Python 4.0

[STINNER Victor]

New submission from STINNER Victor :

The PEP 563: Postponed evaluation of annotations was introduced an opt-in 
feature using "from __future__ import annotations". It is scheduled to become 
the default in Python 4.0.

I would prefer to limit the number of incompatible changes in Python 4.0: it 
should just a "regular" release, with a regular number of incompatible changes. 
The version number change is going to cause enough troubles...

Would it be possible possible to enable postponed evaluation of annotations 
either before or after Python 4.0? For example, can we imagine to enable it by 
default in Python 3.9? If not, what about Python 3.10?

See also the PEP 608 (Coordinated Python release) and bpo-38604 (Schedule 
Py_UNICODE API removal).

--
components: Library (Lib)
messages: 355476
nosy: lukasz.langa, vstinner
priority: normal
severity: normal
status: open
title: [typing] PEP 563: Postponed evaluation of annotations: enable it by 
default before Python 4.0
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

[issue38604] Schedule Py_UNICODE API removal

[STINNER Victor]

New submission from STINNER Victor :

Python 3.3 deprecated the C API functions using Py_UNICODE type. Examples in 
the doc:

* https://docs.python.org/dev/c-api/unicode.html#c.Py_UNICODE
* https://docs.python.org/dev/c-api/unicode.html#deprecated-py-unicode-apis

Currently, functions removal is scheduled for Python 4.0 but I would prefer 
that Python 4.0 doesn't have a long list of removed features, but no more than 
usual. So I'm trying to remove a few functions from Python 3.9, and try to 
prepare removal for others.

Py_UNICODE C API was mostly kept for backward compatibility with Python 2. 
Since Python 2 support ends at the end of the year, can we start to organize 
Py_UNICODE C API removal?

There are multiple questions:

* Should we drop the whole API at once? Or can we/should we start by removing a 
few functions, and then the others?
* Deprecation warnings are emitted at compilation. But I'm not aware of 
DeprecationWarning emited at runtime. IMHO we should emit DesprecationWarning 
at runtime during at least one release, so most developers ignore compilation 
warnings.

I propose to:

* (Right now) write an exhaustive list of all deprecated APIs: functions, 
constants, types, etc.
* Modify C code to emit DeprecationWarning at runtime in Python 3.9
* Experiment a modified Python without these APIs and test how many projects 
are broken by this removal: see PEP 608
* Schedule the actual removal of all these APIS from Python 3.10

Honestly, if the removal is causing too much issues, I'm fine to make slowdown 
the removal. It's just a matter of clearly communicating our intent.

Maybe we should also announce the scheduled removal in What's in Python 3.9 and 
in the capi-sig mailing list.

--
components: Library (Lib)
messages: 355475
nosy: vstinner
priority: normal
severity: normal
status: open
title: Schedule Py_UNICODE API removal
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

[issue18765] unittest needs a way to launch pdb.post_mortem or other debug hooks

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Hi Rémi, I'd also be happy to take a look at your problem, if it's still open, 
do you have patch of what you've done so far?

--
nosy: +benedwards14

___
Python tracker 

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

[issue37330] open(): remove 'U' mode, deprecated since Python 3.3

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +16487
pull_request: https://github.com/python/cpython/pull/16959

___
Python tracker 

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

[issue29612] TarFile.extract() suffers from hard links inside tarball

[TROUVERIE Joachim]

Change by TROUVERIE Joachim :


--
pull_requests: +16486
pull_request: https://github.com/python/cpython/pull/16958

___
Python tracker 

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

[issue22491] Support Unicode line boundaries in regular expression

[Lewis Gaul]

Lewis Gaul  added the comment:

Hi there, I'm running 'EnHackathon' in a couple of weeks, and was wondering if 
this could be a good issue for a small team of first-time contributors with 
experience in C to work on.

Would anyone be able to offer any guidance for where to start in Modules/_sre.c?

--
nosy: +Lewis Gaul

___
Python tracker 

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

[issue38603] inspect.getdoc could examine the __class__ cell for dynamically generated subclasses

[Antony Lee]

Change by Antony Lee :


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

___
Python tracker 

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

[issue38603] inspect.getdoc could examine the __class__ cell for dynamically generated subclasses

[Antony Lee]

New submission from Antony Lee :

Currently, `inspect.getdoc()` fails to inherit docstrings in dynamically 
generated subclasses, such as
```
class Base:
def method(self): "some docstring"

def make_subclass():
class subclass(Base):
def method(self): return super().method()
return subclass

subclass = make_subclass()
inspect.getdoc(subclass.method)  # => returns None
```
because `inspect._findclass()` tries to find the base class by parsing 
`subclass.method.__qualname__` which is 
`"make_subclass..subclass.method"` and chokes over `..`.

In the case where the method does rely on `super()`, there is another way we 
can go back to the "owning" class of the method: by looking up the contents of 
the `__class__` cell (which is set up to make 0-arg super()).

Perhaps a `__class__` cell could even be set up for *all* methods defined in 
dynamically created subclasses (i.e. whose `__qualname__` includes 
`..`), to help with introspection?

--
components: Library (Lib)
messages: 355472
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: inspect.getdoc could examine the __class__ cell for dynamically 
generated subclasses
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

[issue23692] Undocumented feature prevents re module from finding certain matches

[Lewis Gaul]

Lewis Gaul  added the comment:

Hi there, if anyone's able to provide any guidance on this issue I'd be happy 
to take a look into it.

Is this a behaviour that is feasible to fix, or should this just be documented 
in some way as suggested by Evgeny?

--
nosy: +Lewis Gaul

___
Python tracker 

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

[issue15243] Misleading documentation for __prepare__

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Is this still open, does the patch still need a pull request?

--
nosy: +benedwards14

___
Python tracker 

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

[issue16142] ArgumentParser inconsistent with parse_known_args

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Hey this has been open for quite a while, is there anything that needs 
finishing off?

--
nosy: +benedwards14

___
Python tracker 

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

[issue21002] _sre.SRE_Scanner object should have a fullmatch() method

[Lewis Gaul]

Lewis Gaul  added the comment:

Scanner is not documented in CPython's own re documentation: 
https://docs.python.org/3/library/re.html#regular-expression-objects, so I'd 
say there's no obligation to maintain consistency with public APIs.

Is anyone able to make a call on whether this issue should be closed, or 
alternatively give some guidance on what work this issue should encompass?

--
nosy: +Lewis Gaul

___
Python tracker 

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

[issue38602] Add fcntl.F_OFD_XXXX constant

[Dong-hee Na]

Change by Dong-hee Na :


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

___
Python tracker 

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

[issue17306] Improve the way abstract base classes are shown in help()

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Michael are you still interested in doing this, if not can I take it on?

--
nosy: +benedwards14

___
Python tracker 

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

[issue38602] Add fcntl.F_OFD_XXXX constant

[Dong-hee Na]

New submission from Dong-hee Na :

Since Linux 3.15 is released.
fcntl.F_OFD_ is used for python code.
It can be found on GitHub.
(https://github.com/ceph/ceph/blob/41d3fdc554ce920a631c7c6699a383134173fcff/qa/workunits/fs/misc/filelock_interrupt.py#L13)

I am working on this issue.

--
components: Library (Lib)
messages: 355466
nosy: corona10, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add fcntl.F_OFD_ constant
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

[issue38314] Implement unix read_pipe.is_reading() method

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Shubham are you still interested in this, or are you ok with me taking it on?

--
nosy: +benedwards14

___
Python tracker 

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

[issue38534] Version 3.8.0 has released with a wrong MS KB number reference

[Benjamin Edwards]

Benjamin Edwards  added the comment:

Have made a new PR, am just waiting for my CLA to be approved.

--
nosy: +benedwards14

___
Python tracker 

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

[issue38534] Version 3.8.0 has released with a wrong MS KB number reference

[Benjamin Edwards]

Change by Benjamin Edwards :


--
pull_requests: +16483
pull_request: https://github.com/python/cpython/pull/16955

___
Python tracker 

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

[issue38601] Couldn't able to install multiple python minor version in windows due to EXE script

[Kiran Kumar Kotari]

Change by Kiran Kumar Kotari :


--
title: Couldn't able to install multiple python minor version in windows -> 
Couldn't able to install multiple python minor version in windows due to EXE 
script

___
Python tracker 

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

[issue38601] Couldn't able to install multiple python minor version in windows

[Kiran Kumar Kotari]

New submission from Kiran Kumar Kotari :

Today, Python 2.x/3.x Windows installation script is check for any python minor 
versions installed from the same train and updating it. This creates a problem 
of checking the project features. We solved multi-trains like 3.5 and 3.6 
installation using pyenv-win but the minor version was a problem due to EXE 
file validation before installation and if any it updates the same. 

Can you please help us on updating the EXE script to with 
 - validate the minor versions by default
 - off the validate the minor version on installation

This feature helps us with minor version validation.

--
components: Installation
messages: 355463
nosy: kkotari
priority: normal
severity: normal
status: open
title: Couldn't able to install multiple python minor version in windows
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

[issue38351] Modernize email example from %-formatting to f-string

[Lewis Gaul]

Lewis Gaul  added the comment:

Hi all, I'm a newcomer interested in making this small fix, but it looks like 
this has become a bit of a contentious issue. Are there any advances on whether 
this is a desirable fix?

--
nosy: +Lewis Gaul

___
Python tracker 

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

[issue24430] ZipFile.read() cannot decrypt multiple members from Windows 7zFM

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I got carried away refactoring the decrypter for a future scenario where 
> there could be different decrypters (possibly using certificates too) :)

The decrypter was implemented with a generator for performance. The performance 
of decrypting is not critical, but this got us 2x speed up without complicating 
the code. See issue10030. If the support of other decrypters be added, they 
will likely be implemented in C in any case.

> I also think that the `read_init` method in my PR is a useful refactor as it 
> locates all the state that needs to be (re)set when starting a read into the 
> same location.

This is a different issue.

> Would you also be able to take a look at some other PRs I've submitted for 
> zipfile.

Thank you, they look good to me. I left just few comments.

As for the original issue, I have doubts that backward seeking in a compressed 
file is a good idea. But this feature was added, and it worked with encrypted 
files if seek in the range of the buffer, so not working out of the range of 
the buffer is a bug which we should fix.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> 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

[issue38592] Add pt-br to the language switcher at the Python docs website

[Julien Palard]

Julien Palard  added the comment:


New changeset 155a9dc129c129270763525cd3eb2704990e406d by Julien Palard (Miss 
Skeleton (bot)) in branch '3.7':
bpo-38592 Add pt-br switcher to Python Docs website (GH-16924) (GH-16954)
https://github.com/python/cpython/commit/155a9dc129c129270763525cd3eb2704990e406d


--

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[Julien Palard]

Julien Palard  added the comment:


New changeset 955f96f6aae7c1a54d88c3f7a51c2e142ac7e4d4 by Julien Palard (Miss 
Skeleton (bot)) in branch '3.8':
bpo-38592 Add pt-br switcher to Python Docs website (GH-16924) (GH-16953)
https://github.com/python/cpython/commit/955f96f6aae7c1a54d88c3f7a51c2e142ac7e4d4


--

___
Python tracker 

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

[issue37523] zipfile: Raise ValueError for i/o operations on closed zipfile.ZipExtFile

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Could you please test what performance effect it has on read()?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

> If we add the deprecation warning just for 3.9, would the removal release 
> also be pushed forward? 

Yes, deprecating in 3.9 with removal in 3.11 is fine.

Regarding 3.8 release notes update -- not sure if it is needed flr docs-only 
change.

In the current situation, we have so-called *soft deprecation*: bare coroutines 
are deprecated in docs without any code change. This is perfectly fine, we give 
our users extra time to prepare for changes.

--

___
Python tracker 

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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[miss-islington]

miss-islington  added the comment:


New changeset ed2db3113d54a5f8af1b419a9f5fdf3642285c82 by Miss Skeleton (bot) 
in branch '3.7':
bpo-38334: Fix seeking backward on an encrypted zipfile.ZipExtFile. (GH-16937)
https://github.com/python/cpython/commit/ed2db3113d54a5f8af1b419a9f5fdf3642285c82


--

___
Python tracker 

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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[miss-islington]

miss-islington  added the comment:


New changeset 76fbdaa2a693caaa1b8eb34104720fc774ff80df by Miss Skeleton (bot) 
in branch '3.8':
bpo-38334: Fix seeking backward on an encrypted zipfile.ZipExtFile. (GH-16937)
https://github.com/python/cpython/commit/76fbdaa2a693caaa1b8eb34104720fc774ff80df


--
nosy: +miss-islington

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[miss-islington]

Change by miss-islington :


--
pull_requests: +16481
pull_request: https://github.com/python/cpython/pull/16953

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[miss-islington]

Change by miss-islington :


--
pull_requests: +16482
pull_request: https://github.com/python/cpython/pull/16954

___
Python tracker 

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

[issue38592] Add pt-br to the language switcher at the Python docs website

[Julien Palard]

Julien Palard  added the comment:


New changeset 85c6f8c65cd4f7219522c1f304bdfff19f785e7a by Julien Palard (Marco 
Rougeth) in branch 'master':
bpo-38592 Add pt-br switcher to Python Docs website (GH-16924)
https://github.com/python/cpython/commit/85c6f8c65cd4f7219522c1f304bdfff19f785e7a


--

___
Python tracker 

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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[miss-islington]

Change by miss-islington :


--
pull_requests: +16479
pull_request: https://github.com/python/cpython/pull/16951

___
Python tracker 

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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[miss-islington]

Change by miss-islington :


--
pull_requests: +16480
pull_request: https://github.com/python/cpython/pull/16952

___
Python tracker 

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

[issue38334] zipfile: Seeking encrypted file breaks after seeking backwards

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 5c32af7522d908e8c7da0243af37618433289cc5 by Serhiy Storchaka in 
branch 'master':
bpo-38334: Fix seeking backward on an encrypted zipfile.ZipExtFile. (GH-16937)
https://github.com/python/cpython/commit/5c32af7522d908e8c7da0243af37618433289cc5


--

___
Python tracker 

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

[issue38600] Change the mark up of NULL

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue38600] Change the mark up of NULL

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Currently NULL is mostly marked up as *NULL* in the C API documentation 
(although it is marked up as ``NULL`` outside of the C API documentation). It 
is rendered with italic font as function parameters and contradicts with 
formatting other macros and constants with monospace font.

The proposed PR replaces all *NULL* with ``NULL``.

--
assignee: docs@python
components: Documentation
messages: 355452
nosy: docs@python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Change the mark up of NULL
type: enhancement
versions: 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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Kyle Stanley]

Kyle Stanley  added the comment:

> It was the first time I saw a deprecation clearly documented in a final 
> release that didn't have an associated deprecation warning. 

I want to clarify that this may be a more common occurrence than I'm realizing, 
I'm not entirely certain. Also it's not intended at all as a criticism, it just 
surprised me since it was the first time I saw it happen.

--

___
Python tracker 

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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Kyle Stanley]

Kyle Stanley  added the comment:

> I think we can add `DeprecationWarning` for 3.9.

If we add the deprecation warning just for 3.9, would the removal release also 
be pushed forward? 

> Honestly, we just missed the issue when were prepared for 3.8

Yeah that's definitely understandable, there were quite a number of major 
changes made in 3.8. It was the first time I saw a deprecation clearly 
documented in a final release that didn't have an associated deprecation 
warning. 

As for 3.8, I would like to update the whatsnew entry to add a link to this bpo 
issue if that's okay, as it does not at the moment. I recently included the 
entry in a PR that added entries for multiple significant changes for asyncio 
in the 3.8, but I forgot to include the bpo link (mostly because I found it in 
the documentation, rather than from the bpo issue).

--

___
Python tracker 

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

[issue38599] Deprecate creation of asyncio object when the loop is not running

[Andrew Svetlov]

New submission from Andrew Svetlov :

Consider the following code:

import asyncio

q = asyncio.Queue()

async def main():
await asyncio.gather(q.put(1), q.get(1))

asyncio.run(main())


This code just hangs since run() creates a loop but queue is bound with another 
(default) event loop.

The error is confusing and hard-to-debug.

We should raise a warning at least for the case; start from DeprecationWarning 
and make the system stricter later.

asyncio/locks.py is also affected since it has first-class classes (classes 
that instantiated by a user directly without factories).

--
components: asyncio
messages: 355449
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate creation of asyncio object when the loop is not running
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

[issue34790] Deprecate passing coroutine objects to asyncio.wait()

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I think we can add `DeprecationWarning` for 3.9.

Since it is a) just a warning b) already marked as deprecated in docs -- the 
harm is minimal.

Honestly, we just missed the issue when were prepared for 3.8

--

___
Python tracker 

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

[issue37309] idlelib/NEWS.txt for 3.9.0 and backports

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset baf2657eff82f5c33ae8194499d97ba963871655 by Terry Jan Reedy in 
branch '3.7':
[3.7] bpo-37309: First idlelib/NEWS.txt for 3.7.6 (GH-) (#16949)
https://github.com/python/cpython/commit/baf2657eff82f5c33ae8194499d97ba963871655


--

___
Python tracker 

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