[issue35395] Typo in asyncio eventloop documentation

[miss-islington]

miss-islington  added the comment:


New changeset 6627d3ae1e151095fda4ec2592c7cfb759f23669 by Miss Islington (bot) 
in branch '3.7':
bpo-35395: fix typos in asyncio eventloop documentation (GH-10880)
https://github.com/python/cpython/commit/6627d3ae1e151095fda4ec2592c7cfb759f23669


--

___
Python tracker 

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

[issue35395] Typo in asyncio eventloop documentation

[miss-islington]

Change by miss-islington :


--
pull_requests: +10123

___
Python tracker 

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

[issue35395] Typo in asyncio eventloop documentation

[miss-islington]

miss-islington  added the comment:


New changeset 17473347942353946fe455f797a2197cb89c1090 by Miss Islington (bot) 
(Naglis) in branch 'master':
bpo-35395: fix typos in asyncio eventloop documentation (GH-10880)
https://github.com/python/cpython/commit/17473347942353946fe455f797a2197cb89c1090


--
nosy: +miss-islington

___
Python tracker 

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

[issue35402] Upgrade macOS (and Windows?) installer to Tcl/Tk 8.6.9.1

[Ned Deily]

New submission from Ned Deily :

Tcl/Tk 8.6.9 (followed by Tk 8.6.9.1) was released recently.  Among other 
things, they contain fixes for various issues on macOS, some of which have been 
seen by macOS users of IDLE and other tkinter apps, so the macOS installer 
should definitely be updated for 3.7.2, 3.6.8, and 2.7.16.

--
components: Windows, macOS
messages: 331011
nosy: ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade macOS (and Windows?) installer to Tcl/Tk 8.6.9.1
versions: Python 2.7, 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

[issue35401] Upgrade Windows and macOS installers to use OpenSSL 1.1.0j / 1.0.2q

[Ned Deily]

New submission from Ned Deily :

New versions of OpenSSL were released on 2018-11-20.  We should update for 
3.7.2, 3.6.8, and 2.7.16.

--
assignee: christian.heimes
components: SSL, Windows, macOS
messages: 331010
nosy: benjamin.peterson, christian.heimes, ned.deily, paul.moore, 
ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Upgrade Windows and macOS installers to use OpenSSL 1.1.0j / 1.0.2q
versions: Python 2.7, 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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[tzickel]

tzickel  added the comment:

Reverting the code will cause another class of problems, like the reason I 
fixed it. Programs written such as the example that Pablo gave (and what I've 
seen) will quietly leak child processes, file descriptors (for the pipes) and 
memory to a variety degree might not be detected, or in the end detected in a 
big error or crash.

Also in some ResourceWarnings (if not all), the resources are closed in the end 
(like in sockets), here without this code patch you cannot implicitly reclaim 
the resources (because there is a Thread involved here), which I think is a 
high bar for the user to think about.

You can also enable multiprocessing's debug logging to see how the code behaves 
with and without the fix:
https://stackoverflow.com/a/1353037

I also agree with Pablo that there is code in the stdlib that holdes reference 
between child and parent. There is also code that has circular reference (for 
example Python 2's OrderedDict) and that is ok as well (not that this is the 
situation here).

--

___
Python tracker 

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

[issue35399] Sysconfig bug

[Jorge Ramos]

Change by Jorge Ramos :


--
components: +Build

___
Python tracker 

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

[issue35400] PGOMGR : warning PG0188:

[Jorge Ramos]

New submission from Jorge Ramos :

The following command:

Tools\msi\buildrelease.bat -x64

is used to build a 64 bit version (on win_10_64) of python (using visual studio 
2017). 

The following modules did not build correctly because, presumably, the 
corresponding .PGC files could not be found, even when the PGO tests ran 
perfectly well:

_elementtree
_multiprocessing
_ctypes
winsound
pyexpat
_socket
_bz2
_ssl
_lzma
_hashlib
select

See details in the attached file (search for the text "PGOMGR").

--
components: Build
files: missing_pgc_files.txt
messages: 331008
nosy: neyuru
priority: normal
severity: normal
status: open
title: PGOMGR : warning PG0188:
type: compile error
versions: Python 3.6
Added file: https://bugs.python.org/file47970/missing_pgc_files.txt

___
Python tracker 

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

[issue35399] Sysconfig bug

[Jorge Ramos]

New submission from Jorge Ramos :

As can be seen in the file, the sysconfig test fails when profiling (PGO) this 
utility. This is the very same bug as described in issue#35299 
https://bugs.python.org/issue35299 but in distutils.

The problem is that when the test for sysconfig runs, it does not find the file 
pyconfig.h in the include directory. If this file is manually copied there, the 
test runs OK.

--
files: sysconfig_bug.txt
messages: 331007
nosy: neyuru
priority: normal
severity: normal
status: open
title: Sysconfig bug
type: compile error
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47969/sysconfig_bug.txt

___
Python tracker 

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

[issue35398] SQLite incorrect row count for UPDATE

[mike bayer]

Change by mike bayer :


--
nosy: +zzzeek

___
Python tracker 

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

[issue11107] Cache constant "slice" instances

[Josh Rosenberg]

Change by Josh Rosenberg :


--
versions: +Python 3.8 -Python 3.5

___
Python tracker 

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

[issue35398] SQLite incorrect row count for UPDATE

[Montana Low]

New submission from Montana Low :

SQLite driver returns an incorrect row count (-1) for UPDATE statements that 
begin with a comment.

Downstream Reference:
https://github.com/sqlalchemy/sqlalchemy/issues/4396


Test Case:

```
import sqlite3

conn = sqlite3.connect(":memory:")

cursor = conn.cursor()

cursor.execute("""
CREATE TABLE foo (
id INTEGER NOT NULL,
updated_at DATETIME,
PRIMARY KEY (id)
)
""")

cursor.execute("""
/* watermarking bug */
INSERT INTO foo (id, updated_at) VALUES (?, ?)
""", [1, None])


cursor.execute("""
UPDATE foo SET updated_at=? WHERE foo.id = ?
""", ('2018-12-02 14:55:57.169785', 1))

assert cursor.rowcount == 1

cursor.execute("""
/* watermarking bug */
UPDATE foo SET updated_at=? WHERE foo.id = ?
""", ('2018-12-03 14:55:57.169785', 1))

assert cursor.rowcount == 1
```

--
components: Library (Lib)
messages: 331006
nosy: Montana Low
priority: normal
severity: normal
status: open
title: SQLite incorrect row count for UPDATE
versions: Python 2.7, Python 3.6

___
Python tracker 

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

[issue35390] ctypes not possible to pass NULL c_void_p in structure by reference

[Eryk Sun]

Eryk Sun  added the comment:

Your example uses POINTER(c_double), not c_void_p. There's no problem with an 
actual pointer object (i.e. subclass of ctypes._Pointer). The problem is with 
simple types (i.e. immediate subclasses of ctypes._SimpleCData), including 
simple pointer types (i.e. c_void_p, c_char_p, c_wchar_p). Simple types are 
automatically converted to equivalent Python types when returned from functions 
or accessed in aggregates (i.e. structs and arrays). This is generally 
convenient, but at times it's a serious problem. 

Note that I said this is the case only for immediate subclasses of 
_SimpleCData. We can work around the behavior by using a subclass of the given 
simple type. For example:

class my_wchar_p(ctypes.c_wchar_p): 
pass

class T(ctypes.Structure):
_fields_ = (('s1', ctypes.c_wchar_p), 
('s2', my_wchar_p))

>>> t = T('abc', 'def')
>>> t.s1
'abc'
>>> t.s2
my_wchar_p(140497806976112)
>>> t.s2.value
'def'

If desired, we can retain the automatic conversion for function results by 
defining a staticmethod or classmethod named "_check_retval_" on the subclass. 
This method takes the result as parameter to be checked, possibly converted, 
and returned.

One exception is that [wide-]character arrays always get converted into 
bytes/strings when accessed as fields of a struct. This is implemented in 
PyCField_FromDesc in Modules/_ctypes/cfield.c. We can't easily work around this 
hack because it doesn't check whether the base type is an immediate subclass of 
_SimpleCData. Instead we have to use the undocumented `offset` attribute. We 
can hide this workaround with a private field and a property. For example:

class T(ctypes.Structure):
_fields_ = (('s1', ctypes.c_wchar * 10),
('_s2', ctypes.c_wchar * 10))
@property
def s2(self):
offset = type(self)._s2.offset
return (ctypes.c_wchar * 10).from_buffer(self, offset)

>>> t = T('abc', 'def')
>>> t._s2
'def'
>>> t.s2
<__main__.c_wchar_Array_10 object at 0x7fc82c3a6510>
>>> t.s2.value
'def'

--
nosy: +eryksun

___
Python tracker 

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

[issue35305] subprocess.Popen(['/sbin/ldconfig', '-p'], stdin=PIPE) itself hangs/deadlocks (Linux)

[HenrikB]

HenrikB  added the comment:

Thank you both for the comments and suggests.  Before I'm getting to the 
"interesting" part, first to the "easy" one:

>> What is also useful to know, is that I'm observing this on a legacy RHEL 6 
>> system *with a customized kernel* part of the Scyld ClusterWare 
>> (https://www.penguincomputing.com/products/software/scyld-clusterware/) that 
>> *cannot* be updated:

> Do you mean this trouble is happened only on the system?
> Or can this trouble be reproducible on normal Linux kernel?

The issue only occurs on this particular setup and I have not seen it on the 
two other RHEL/Centos systems I have access to.  More below.


> Are you able to reproduce the issue with Python 3?

Yes, I can confirm that I'm seeing this issue also with Python 3.6.5 where:

import subprocess
p = subprocess.Popen(['/sbin/ldconfig', '-p'], stdout=subprocess.PIPE)

stalls.


> Can you please also try http://pypi.org/project/subprocess32/?

Confirming that the following stalls on both Python 2.7.9 and 2.7.15:

import subprocess32
p = subprocess32.Popen(['/sbin/ldconfig', '-p'], stdout=subprocess32.PIPE)



POOR MAN'S DEBUGGING:

Some more narrowing down on exactly where in the code it get stuck, with the 
disclaimer that I'm kind of a rookie when it comes to Python so I don't really 
know how to debug interactively etc.

Using poor man's debug, that is, lots of print statements, I've narrowed down 
the stall of

import subprocess
p = subprocess.Popen(['/sbin/ldconfig', '-p'], stdout=subprocess.PIPE)

to occur in the call:

  _execute_child(args = ['/sbin/ldconfig', '-p'], executable = None, preexec_fn 
= None, close_fds = False, cwd = None, env = None, universal_newlines = False, 
startupinfo = None, creationflags = 0, shell = False, to_close = set([3, 4]), 
p2cread = None, p2cwrite = None, c2pread = 3, c2pwrite = 4, errread = None, 
errwrite = None)

where the *child* process (`self.pid == 0`) get stuck while calling 
_dup2(c2pwrite = 4, 1) which in turn calls os.dup2(a = 4, b = 1).  The *parent* 
process get stuck in the call data = _eintr_retry_call(os.read, errpipe_read, 
1048576).  Not sure if that rules out certain things, or it just confirms what 
is already known/what strace is already saying.



SOME MORE TROUBLESHOOTING:

> So I think there are some bug in your kernel, relating to CLOEXEC.

I'm also leaning towards the issue is related to the kernel.  What is really 
interesting is that executable '/sbin/ldconfig' does *not* exist:

$ ls /sbin/ldconfig
ls: cannot access /sbin/ldconfig: No such file or directory

but yet, I can call it:

$ /sbin/ldconfig -p | wc -c
102460

and the output is indeed valid(*).  For me, this strongly suggests that this 
particular system call is intercepted.  I don't know the details, but I think 
this reflects the gist of the Scyld Clusterware kernel where it intercepts 
certain system calls makes a multi-node computer cluster to appear as one 
machine.  (*) By valid I mean '/sbin/ldconfig -p' gives identical out on the 
compute nodes where this problem occurs as on the master node (where 
/sbin/ldconfig indeed exists) which Scyld is trying to "mirror" on the compute 
nodes.  (I don't ask you to waste brain cycles on trying to follow this but I 
thought it's useful to put all this down for the record and potential future 
readers.)


> Maybe, you can consult with the company.

I will try to reach out to them to have them confirm my troubleshooting and see 
if this has been fixed in a later release of theirs.   (Unfortunately, it won't 
help our current legacy system, which we are slowly moving away.  Regardless, 
by posting this here, I hope I'll spare at least one other person some 
troubleshooting if they find this post; it caused me and lots of other users 
100's of hours of confusion and troubleshooting before we got this far.)


It would also be interesting to understand exactly what causes the stall.  Is 
it indeed the pipe that gets filled up?  Is that because the kernel does *not* 
respect the pipe limit and just dumps all output at once (> 65,536 bytes), i.e. 
it is a bug?  Or is it that Python or one of its dependencies runs into a race 
condition because, say, it does not have a chance to set up the parent-child 
communication before the child (== the kernel) dumps too much data?

Inada Naoki, does the above new info give further evidence to your comment:

> So I think there are some bug in your kernel, relating to CLOEXEC.

or did it possibly bring something new to the table?  (I'm not too familiar 
with the Linux system calls and what to infer from strace logs).



A BROKEN DESIGN?

Finally, I don't know if the fact that `/sbin/ldconfig` does not exist but you 
can yet call it is (i) poorly designed kernel, or (ii) a valid design in the 
Unix world.  I don't know the answer to this and I don't claim one is more 
correct than the other.  I also don't know if there are other kernels out there 
that does 

[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals

[kernc]

Change by kernc :


--
nosy: +kernc

___
Python tracker 

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

[issue35373] PyInit_timezone() must return a value

[STINNER Victor]

Change by STINNER Victor :


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

[issue35397] Undeprecate and document urllib.parse.unwrap

[Steven D'Aprano]

New submission from Steven D'Aprano :

The urllib.parse module contains an undocumented function unwrap:

unwrap('') --> 'type://host/path'

This is useful. I've been re-inventing this function in many of my scripts, 
because I didn't know it existed (not documented!) and only stumbled across it 
by accident today, where I see it was deprecated in  #27485 but I can't see any 
reason for the deprecation.

If not for the deprecation, I would certainly use this unwrap function in 
preference to rolling my own.

It seems to me that this might have been a case of an over-enthusiastic change. 
#27485 talks about deprecating the various split* functions, which are 
officially redundant (urlparse and urlsplit are preferred) but doesn't talk 
about unwrap, which is useful and (in my opinion) should have been documented 
rather than deprecated.

--
messages: 331003
nosy: cheryl.sabella, serhiy.storchaka, steven.daprano
priority: normal
severity: normal
status: open
title: Undeprecate and document urllib.parse.unwrap
type: enhancement
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

[issue35390] ctypes not possible to pass NULL c_void_p in structure by reference

[Martin Panter]

Martin Panter  added the comment:

This problem is common to structure fields in general, not just "c_void_p". I 
recently encountered it with a different type (don't remember the type now, but 
I notice plain types like c_int share the problem). I found 

 which suggests using the undocumented "offset" attribute of the structure 
fields. In your case you might be able to do:

  print_ptraddress(byref(effect, Effect.ptr.offset))

however the pointer data type will be wrong. Maybe you can also do

  print_ptraddress(c_void_p.from_buffer(effect, Effect.ptr.offset))

although there is no automatic type checking that Effect.ptr refers to a 
c_void_p data type.

Unless there is a better way, I think the "offset" attribute of structure 
fields should be documented.

--
nosy: +martin.panter

___
Python tracker 

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

[issue35373] PyInit_timezone() must return a value

[miss-islington]

miss-islington  added the comment:


New changeset f455353bc0d195e092f09fec92ed16e9be02b7b1 by Miss Islington (bot) 
in branch '3.6':
[3.7] bpo-35373: Fix PyInit_timezone() error handling (GH-10864)
https://github.com/python/cpython/commit/f455353bc0d195e092f09fec92ed16e9be02b7b1


--
nosy: +miss-islington

___
Python tracker 

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

[issue35373] PyInit_timezone() must return a value

[STINNER Victor]

STINNER Victor  added the comment:

In Python 2.7, inittimezone() is simpler and so less likely to fail. I propose 
to leave Python 2.7 unchanged.

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I disagree that a child should keep its parent alive.

But this is normal across the standard library. For example, here is how a 
deque iterator keeps the deque alive:

>>> x = deque([1,2,3])
>>> deque_iter = iter(x)
>>> deque_weakref = weakref.ref(x)
>>> del x
>>> gc.collect()
>>> gc.get_referrers(deque_weakref())
[<_collections._deque_iterator object at 0x024447ED6EA8>]

Here, the deque iterator is the *only* reference to the deque. When we destroy 
it, the deque is destroyed:
>>> del deque_iter
>>> gc.collect()
>>> deque_weakref()
None

--

___
Python tracker 

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

[issue35373] PyInit_timezone() must return a value

[miss-islington]

Change by miss-islington :


--
pull_requests: +10122

___
Python tracker 

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

[issue35373] PyInit_timezone() must return a value

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 5eb78c75128187a36d8e983027632fa51cc2ff4d by Victor Stinner in 
branch '3.7':
[3.7] bpo-35373: Fix PyInit_timezone() error handling (GH-10864)
https://github.com/python/cpython/commit/5eb78c75128187a36d8e983027632fa51cc2ff4d


--

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[STINNER Victor]

STINNER Victor  added the comment:

> I found the weird code in the example in several projects. I have corrected 
> it to use the pool as a context manager or to call close(), but this means 
> that users are doing this and it used to work and not it does not: 
> technically is a regression.

That's why I'm asking for a revert :-) I suggest to revert this change 
immediately from 2.7, 3.6 and 3.7, and later see what can be done for master.

Even if we design carefully an API, there will be always someone to misuse it 
:-) I would prefer to stop promoting such bad code and find a transition to 
more correct code.

I disagree that a child should keep its parent alive.

I would be ok to use a *weak reference* from the child to the parent to detect 
when the parent goes away, and maybe trigger an action in that case. For 
example, raise an exception or log a warning.

--

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I'm not comfortable with the fix. I cannot explain why but I feel like adding 
> a strong dependency from a child to its parent is going to lead to more bugs, 
> not less. It sounds like a recipe for reference cycles. Maybe I'm just plain 
> wrong.

The pool child objects (imap iterators, async results...etc) need to keep a 
reference to the parent because if not, the caller is in charge of doing that 
and that may lead to bugs. Is the same scenario as if I get a dictionary 
iterator and then I destroy my reference to the dictionary: if the iterator 
does not keep a reference to the parent (the dictionary) it will not be 
possible to be used in the future. Indeed, we can see that this is what happens:

I'm not comfortable with the fix. I cannot explain why but I feel like adding a 
strong dependency from a child to its parent is going to lead to more bugs, not 
less. It sounds like a recipe for reference cycles. Maybe I'm just plain wrong.

>>> x = {1:2}
>>> y = iter(x)
>>> gc.get_referrers(x)
[, 
{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': 
, '__spec__': None, 
'__annotations__': {}, '__builtins__': , 'y': 
, 'gc': , 'x': {1: 2}}
]

We can see that the dict_keyiterator refers to the dictionary, keeping it alive.

Here we have the same situation: if we do not keep the pool alive, the iterator 
will hang when iterating because the jobs won't get finished.

>At this point, I would like that someone explains to me what the problem is. 
>https://github.com/python/cpython/pull/10852 is a solution, ok, but what is 
>the problem? What does the code hangs, whereas >previously it was fine? Is the 
>example code really correct? Do we want to support such usage?

The code hangs because the pool was not being destroyed before due to the 
reference cycle between the pool and an internal object (a Thread). Now it 
hangs because the worker thread is destroyed with the pool as no references are 
kept to it and the job that the iterator is waiting on is never finished.

>I understand that msg330864 rely on black magic to expect that it's going to 
>be fine. The lifetime of the pool is implicit and it sounds like a bad design. 
>I don't want to endorse that.

I found the weird code in the example in several projects. I have corrected it 
to use the pool as a context manager or to call close(), but this means that 
users are doing this and it used to work and not it does not: technically is a 
regression.

--

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I'm not comfortable with the fix. I cannot explain why but I feel like adding 
> a strong dependency from a child to its parent is going to lead to more bugs, 
> not less. It sounds like a recipe for reference cycles. Maybe I'm just plain 
> wrong.

The pool child objects (imap iterators, async results...etc) need to keep a 
reference to the parent because if not, the caller is in charge of doing that 
and that may lead to bugs. Is the same scenario as if I get a dictionary 
iterator and then I destroy my reference to the dictionary: if the iterator 
does not keep a reference to the parent (the dictionary) it will not be 
possible to be used in the future. Indeed, we can see that this is what happens:

>>> x = {1:2}
>>> y = iter(x)
>>> gc.get_referrents(x)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'gc' has no attribute 'get_referrents'
>>> gc.get_referrers(x)
[, 
{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': 
, '__spec__': None, 
'__annotations__': {}, '__builtins__': , 'y': 
, 'gc': , 'x': {1: 2}}
]

We can see that the dict_keyiterator refers to the dictionary, keeping it alive.

Here we have the same situation: if we do not keep the pool alive, the iterator 
will hang when iterating because the jobs won't get finished.

>At this point, I would like that someone explains to me what the problem is. 
>https://github.com/python/cpython/pull/10852 is a solution, ok, but what is 
>the problem? What does the code hangs, whereas >previously it was fine? Is the 
>example code really correct? Do we want to support such usage?

The code hangs because the pool was not being destroyed before due to the 
reference cycle between the pool and an internal object (a Thread). Now it 
hangs because the worker thread is destroyed with the pool as no references are 
kept to it and the job that the iterator is waiting on is never finished.

>I understand that msg330864 rely on black magic to expect that it's going to 
>be fine. The lifetime of the pool is implicit and it sounds like a bad design. 
>I don't want to endorse that.

I found the weird code in the example in several projects. I have corrected it 
to use the pool as a context manager or to call close(), but this means that 
users are doing this and it used to work and not it does not: technically is a 
regression.

--

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I'm not comfortable with the fix. I cannot explain why but I feel like adding 
> a strong dependency from a child to its parent is going to lead to more bugs, 
> not less. It sounds like a recipe for reference cycles. Maybe I'm just plain 
> wrong.

The pool child objects (imap iterators, async results...etc) need to keep a 
reference to the parent because if not, the caller is in charge of doing that 
and that may lead to bugs. Is the same scenario as if I get a dictionary 
iterator and then I destroy my reference to the dictionary: if the iterator 
does not keep a reference to the parent (the dictionary) it will not be 
possible to be used in the future. Indeed, we can see that this is what happens:

I'm not comfortable with the fix. I cannot explain why but I feel like adding a 
strong dependency from a child to its parent is going to lead to more bugs, not 
less. It sounds like a recipe for reference cycles. Maybe I'm just plain wrong.

>>> x = {1:2}
>>> y = iter(x)
>>> gc.get_referrents(x)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'gc' has no attribute 'get_referrents'
>>> gc.get_referrers(x)
[, 
{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': 
, '__spec__': None, 
'__annotations__': {}, '__builtins__': , 'y': 
, 'gc': , 'x': {1: 2}}
]

We can see that the dict_keyiterator refers to the dictionary, keeping it alive.

Here we have the same situation: if we do not keep the pool alive, the iterator 
will hang when iterating because the jobs won't get finished.

>At this point, I would like that someone explains to me what the problem is. 
>https://github.com/python/cpython/pull/10852 is a solution, ok, but what is 
>the problem? What does the code hangs, whereas >previously it was fine? Is the 
>example code really correct? Do we want to support such usage?

The code hangs because the pool was not being destroyed before due to the 
reference cycle between the pool and an internal object (a Thread). Now it 
hangs because the worker thread is destroyed with the pool as no references are 
kept to it and the job that the iterator is waiting on is never finished.

>I understand that msg330864 rely on black magic to expect that it's going to 
>be fine. The lifetime of the pool is implicit and it sounds like a bad design. 
>I don't want to endorse that.

I found the weird code in the example in several projects. I have corrected it 
to use the pool as a context manager or to call close(), but this means that 
users are doing this and it used to work and not it does not: technically is a 
regression.

--

___
Python tracker 

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

[issue35377] urlparse doesn't validate the scheme

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I'm changing the name to better describe the problem, and suggest a better 
solution.

The urlparse.urlsplit and .urlunsplit functions currently don't validate the 
scheme argument, if given. According to the RFC:

   Scheme names consist of a sequence of characters. The lower case
   letters "a"--"z", digits, and the characters plus ("+"), period
   ("."), and hyphen ("-") are allowed. For resiliency, programs
   interpreting URLs should treat upper case letters as equivalent to
   lower case in scheme names (e.g., allow "HTTP" as well as "http").

https://www.ietf.org/rfc/rfc1738.txt

If the scheme is specified, I suggest it should be normalised to lowercase and 
validated, something like this:

# untested
if scheme:
# scheme_chars already defined in module
badchars = set(scheme) - set(scheme_chars)
if badchars:
raise ValueError('"%c" is invalid in URL schemes' % badchars.pop())
scheme = scheme.lower()


This will help avoid errors such as passing 'http://' as the scheme.

--
keywords:  -patch
stage: patch review -> 
title: urlsplit scheme argument broken -> urlparse doesn't validate the scheme
versions: +Python 3.8 -Python 2.7, Python 3.7

___
Python tracker 

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

[issue35396] Add support for __fspath__ to fnmatch.fnmatchase and filter

[Andrés Delfino]

Change by Andrés Delfino :


--
keywords: +patch
pull_requests: +10121
stage:  -> patch review

___
Python tracker 

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

[issue35396] Add support for __fspath__ to fnmatch.fnmatchase and filter

[Andrés Delfino]

New submission from Andrés Delfino :

Both fnmatch.fnmatchase and fnmatch.filter (in Unix) do not support path-like 
objects.

This is inconvenient, for example, when taking advantage of os.scandir and 
working with os.DirEntry objets.

Also, fnmatch.filter in Windows does support path-like objects, since it uses 
os.path.normcase (which works with path-like objects), so the change for Unix 
would add consistency.

I propose for both functions to accept path-like objects, and in the case of 
fnmatch.filter, to return the path-like object if it matches the pattern (as it 
does now for Windows).

--
components: Library (Lib)
messages: 330992
nosy: adelfino
priority: normal
severity: normal
status: open
title: Add support for __fspath__ to fnmatch.fnmatchase and filter
type: enhancement
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

[issue35395] Typo in asyncio eventloop documentation

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Would you create a PR with a fix?

--
nosy: +asvetlov

___
Python tracker 

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

[issue35395] Typo in asyncio eventloop documentation

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Sorry, you did already

--

___
Python tracker 

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

[issue35395] Typo in asyncio eventloop documentation

[Naglis]

Change by Naglis :


--
keywords: +patch
pull_requests: +10119
stage:  -> patch review

___
Python tracker 

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

[issue35395] Typo in asyncio eventloop documentation

[Naglis]

New submission from Naglis :

loop.add_writer and loop.add_signal_handler have *callback* in their 
signatures, but in their documentation regarding functools.partial usage the 
function is referred to as *func*.

--
assignee: docs@python
components: Documentation
messages: 330989
nosy: docs@python, naglis
priority: normal
severity: normal
status: open
title: Typo in asyncio eventloop documentation

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[STINNER Victor]

STINNER Victor  added the comment:

tzickel:
> A. The documentation explicitly says: "When the pool object is garbage 
> collected terminate() will be called immediately." (Happened till a code 
> refactor 9 years ago introduced this bug).

It is a *very bad* practice to rely on __del__. Don't do that. That's why we 
introduced ResourceWarning.


tzickel:
> https://github.com/python/cpython/blob/master/Lib/multiprocessing/util.py#L147
>  (Till the end of the file almost)

Is this API *incompatible* with pool.close()? Explicitly release resources?


Pablo:
> Víctor, I have a PR fixing this in: (...) The fix is really simple, so I 
> think we should fix it and not revert the change on this case.

I'm not comfortable with the fix. I cannot explain why but I feel like adding a 
strong dependency from a child to its parent is going to lead to more bugs, not 
less. It sounds like a recipe for reference cycles. Maybe I'm just plain wrong.

At this point, I would like that someone explains me what the problem is. 
https://github.com/python/cpython/pull/10852 is a solution, ok, but what is the 
problem? What does the code hangs, whereas previously it was fine? Is the 
example code really correct? Do we want to support such usage?

I understand that msg330864 rely on black magic to expect that it's going to be 
fine. The lifetime of the pool is implicit and it sounds like a bad design. I 
don't want to endorse that.

--

___
Python tracker 

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

[issue17185] unittest mock create_autospec doesn't correctly replace mocksignature

[Chris Withers]

Chris Withers  added the comment:

xtreak - great to see action on this! First step would be to add a unit test 
for the failure case I reported. I like the tests you have too, but would be 
good to see the specific failure case covered too.

Beyond that, if we can get all the the new tests passing, then I'd say you're 
there!

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

[issue35226] mock.call equality surprisingly broken

[Chris Withers]

Change by Chris Withers :


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

[issue35394] Add __slots__ = () to asyncio protocols

[Andrew Svetlov]

New submission from Andrew Svetlov :

Protocols have no members.

Adding empty slots doesn't harm any existing code but it allows to write proper 
protocol implementation with slot-based class.

--
components: asyncio
messages: 330986
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add __slots__ = () to asyncio protocols
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

[issue35226] mock.call equality surprisingly broken

[Chris Withers]

Chris Withers  added the comment:


New changeset e8f9e4785caeef8a68bb7859280e91a4cb424b79 by Chris Withers (Miss 
Islington (bot)) in branch '3.7':
bpo-35226: Fix equality for nested unittest.mock.call objects. (GH-10555)
https://github.com/python/cpython/commit/e8f9e4785caeef8a68bb7859280e91a4cb424b79


--

___
Python tracker 

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

[issue35226] mock.call equality surprisingly broken

[Chris Withers]

Chris Withers  added the comment:


New changeset 67e6136a6d5c07141d4dba820c450a70db7aedd5 by Chris Withers (Miss 
Islington (bot)) in branch '3.6':
bpo-35226: Fix equality for nested unittest.mock.call objects. (GH-10555)
https://github.com/python/cpython/commit/67e6136a6d5c07141d4dba820c450a70db7aedd5


--

___
Python tracker 

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

[issue35226] mock.call equality surprisingly broken

[miss-islington]

Change by miss-islington :


--
pull_requests: +10118

___
Python tracker 

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

[issue35226] mock.call equality surprisingly broken

[Chris Withers]

Chris Withers  added the comment:


New changeset 8ca0fa9d2f4de6e69f0902790432e0ab2f37ba68 by Chris Withers in 
branch 'master':
bpo-35226: Fix equality for nested unittest.mock.call objects. (#10555)
https://github.com/python/cpython/commit/8ca0fa9d2f4de6e69f0902790432e0ab2f37ba68


--

___
Python tracker 

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

[issue35226] mock.call equality surprisingly broken

[miss-islington]

Change by miss-islington :


--
pull_requests: +10117

___
Python tracker 

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

[issue35380] Enable TCP_NODELAY for proactor event loop

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset fe91e9ba08a8854e2149398386702828fe3c0038 by Andrew Svetlov (Miss 
Islington (bot)) in branch '3.7':
[3.7] bpo-35380: Enable TCP_NODELAY for proactor event loop (GH-10867) 
(GH-10872)
https://github.com/python/cpython/commit/fe91e9ba08a8854e2149398386702828fe3c0038


--

___
Python tracker 

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

[issue35310] select which was interrupted by EINTR isn't re-run if the timeout has passed

[Oran Avraham]

Change by Oran Avraham :


--
pull_requests: +10116

___
Python tracker 

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

[issue35387] Dialogs on IDLE are accompanied by a small black window

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I just updated my Macbook to Mohave.  As implied, I do not see this on 
installed 3.7.1 with 8.6.8.  But this is a heads-up for future releases.  
Someone with both a Mac Python development environment + tip 8.6 would have to 
look at this now.

When the packaged tcl/tk in the repository is updated, 
idlelib/idle_test/htest.py should be run (in addition to test/test_idle.py) to 
see if the new tcl/tk introduces any visual artifacts.  Htest passes 
'htest=True' to ConfigDialog.__init__, but that only affects dialog placement.  
 Kevin, can you run htest on your system?

I don't understand "the dialog's [wm transient] implementation is part of the 
issue; the parent windows for the dialog are not hidden when run against the Tk 
tip,"  The transient call is 'self.transient(parent)' and the parent is the 
editor-based window, which is not blank and which should not be hidden.  If tk 
adds a new 3rd blank window, that seems like a tk bug to me.

--
nosy: +ned.deily, taleinat

___
Python tracker 

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

[issue35393] Typo in documentation

[Filip Bengtsson]

Filip Bengtsson  added the comment:

https://github.com/python/cpython/pull/10876/commits/00f39c15a13377f3920c72267b2b78a043d9b8ab

--

___
Python tracker 

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

[issue35335] msgfmt should be able to merge more than one po file

[s-ball]

s-ball  added the comment:

Currently my main use case is to be able to compile one or more po file(s) from 
a Python script, so I just need to be able to repeatedly call make from that 
script - which was broken per issue 9741

To be honest, I must acknowledge that I initially thought that compiling more 
than one po file was a common use case, and I only later realized that it was 
not. But as it was already (partially) allowed by msgfmt.py, I have just fixed 
the problems and added tests for it.

BTW, I am also the author of last commit, but I have written it on a box where 
I had forgotten to correctly initialize git

--

___
Python tracker 

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

[issue35393] Typo in documentation

[Eric V. Smith]

Eric V. Smith  added the comment:

Can you be more specific? There's not enough information here to take any 
action.

--
nosy: +eric.smith

___
Python tracker 

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

[issue35335] msgfmt should be able to merge more than one po file

[Éric Araujo]

Éric Araujo  added the comment:

I am curious about the use cases for this feature!

--

___
Python tracker 

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

[issue35335] msgfmt should be able to merge more than one po file

[SilentGhost]

Change by SilentGhost :


--
nosy: +eric.araujo, ezio.melotti

___
Python tracker 

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

[issue35377] urlsplit scheme argument broken

[devkral]

devkral  added the comment:

ah, I get the idea behind urlunsplit. But still:
for e.g. http, http:/// is invalid. These urls are invalid for e.g. requests.
May I ask:
urllib.parse is for web protocol urls? If yes, then there should be an option 
which defaults to my version.

--

___
Python tracker 

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

[issue35393] Typo in documentation

[Filip Bengtsson]

New submission from Filip Bengtsson :

There are 256 characters in the range 0–255.

--
assignee: docs@python
components: Documentation
messages: 330975
nosy: autom, docs@python
priority: normal
pull_requests: 10114
severity: normal
status: open
title: Typo in documentation

___
Python tracker 

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

[issue9741] msgfmt.py generates invalid mo because msgfmt.make() does not clear dictionary

[s-ball]

Change by s-ball :


--
pull_requests: +10113
stage: test needed -> patch review

___
Python tracker 

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

[issue35335] msgfmt should be able to merge more than one po file

[s-ball]

Change by s-ball :


--
keywords: +patch
pull_requests: +10112
stage:  -> patch review

___
Python tracker 

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

[issue35380] Enable TCP_NODELAY for proactor event loop

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +10111

___
Python tracker 

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

[issue35357] unittest.mock.call can't represent calls to a method called 'parent'

[Andrew Dunai]

Change by Andrew Dunai :


--
keywords: +patch
pull_requests: +10110
stage:  -> patch review

___
Python tracker 

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

[issue35380] Enable TCP_NODELAY for proactor event loop

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 3bc0ebab17bf5a2c29d2214743c82034f82e6573 by Andrew Svetlov in 
branch 'master':
bpo-35380: Enable TCP_NODELAY for proactor event loop (#10867)
https://github.com/python/cpython/commit/3bc0ebab17bf5a2c29d2214743c82034f82e6573


--

___
Python tracker 

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

[issue35380] Enable TCP_NODELAY for proactor event loop

[miss-islington]

Change by miss-islington :


--
pull_requests: +10109

___
Python tracker 

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

[issue35392] Create asyncio/sockutils.py

[Andrew Svetlov]

New submission from Andrew Svetlov :

As discussed with Yuri on 
https://github.com/python/cpython/pull/10867#discussion_r238395192

Candidate functions to move into the helper modules:
* _set_nodelay()
* _ipaddr_info()
* _set_reuseport()

--
components: asyncio
messages: 330973
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Create asyncio/sockutils.py
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

[issue35391] threading.RLock exception handling while waiting

[Omer Bartal]

New submission from Omer Bartal :

(tested on python 2.7)

Created a threading.Condition(threading.RLock())
A piece of code acquires the lock using a with block and waits (for a notify)
While wait() is running a KeyboardInterrupt is raised
An exception is raised while exiting the lock's with block:
  File "/usr/lib/python2.7/threading.py", line 289, in __exit__
return self.__lock.__exit__(*args)
  File "/usr/lib/python2.7/threading.py", line 216, in __exit__
self.release()
  File "/usr/lib/python2.7/threading.py", line 204, in release
raise RuntimeError("cannot release un-acquired lock")

example code running on the main thread:
def waiting(lock): # (the lock was created using Condition(RLock()))
  with lock:
lock.wait(timeout=xxx) # while waiting a keyboard interrupt is raised

The issue is caused because threading.RLock doesn't handle the exception 
correctly:
def _acquire_restore(self, count_owner):
count, owner = count_owner
self.__block.acquire()
self.__count = count
self.__owner = owner
if __debug__:
self._note("%s._acquire_restore()", self)

The exception is raised after the acquire() returns and the count and owner are 
not restored.

The problem was solved using the following fix (added try, finally):
def _acquire_restore(self, count_owner):
count, owner = count_owner
try:
self.__block.acquire()
finally:
self.__count = count
self.__owner = owner
if __debug__:
self._note("%s._acquire_restore()", self)


Looking at the code, this issue exists in python 3.8 as well.

--
components: Library (Lib)
messages: 330972
nosy: Omer Bartal
priority: normal
severity: normal
status: open
title: threading.RLock exception handling while waiting
type: crash
versions: Python 2.7, Python 3.4, Python 3.5, 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

[issue35357] unittest.mock.call can't represent calls to a method called 'parent'

[Andrew Dunai]

Andrew Dunai  added the comment:

I was considering wrapping a `unittest.mock._Call` class definition within a 
function that would contain name & parent as local variables (arguments). Thus 
they would be accessible within the `_Call` class, but wouldn't be accessible 
from the outside. However this would make them inaccessible from other 
instances of `_Call`. So I think I'll stick to the more trivial solution of 
renaming them to `_mock_name` and `_mock_parent` to conform to the rest of the 
module :)

--

___
Python tracker 

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

[issue25567] shlex.quote doesn't work on bytestrings

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +10106

___
Python tracker 

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

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I submitted Gaurav's patch as PR 10870.  Please review.

--

___
Python tracker 

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

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

[Alexander Belopolsky]

Change by Alexander Belopolsky :


--
pull_requests: +10105
stage: needs patch -> patch review

___
Python tracker 

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

[issue35267] reproducible deadlock with multiprocessing.Pool

[dzhu]

dzhu  added the comment:

Given the hairiness of the deadlock, I think I would rather let someone who has 
more experience with the codebase in general handle it, but I can come back to 
it if it doesn't get addressed.

--

___
Python tracker 

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

[issue35357] unittest.mock.call can't represent calls to a method called 'parent'

[Andrew Dunai]

Andrew Dunai  added the comment:

I see 2 most applicable ways to do it:

- Hide .parent and .name by mangling
- Define them within the mock class definition scope, but not within the class 
itself.

As long as those are accessed only from within the mock class, I think second 
method would be better as it would completely remove them from mock's 
attributes.

--

___
Python tracker 

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

[issue35357] unittest.mock.call can't represent calls to a method called 'parent'

[Chris Withers]

Chris Withers  added the comment:

Not sure I follow the second option, I was thinking of just _mock_parent and 
_mock_name when I logged this.

Happy to see a PR for either though!

--

___
Python tracker 

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

[issue35357] unittest.mock.call can't represent calls to a method called 'parent'

[Chris Withers]

Chris Withers  added the comment:

Go for it! :-)

--

___
Python tracker 

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

[issue35357] unittest.mock.call can't represent calls to a method called 'parent'

[Andrew Dunai]

Andrew Dunai  added the comment:

I've just stumbled upon this issue while looking for a good first issue to 
contribute on. If the community agrees this is something that needs to be done, 
I'll gladly work on this.

--
nosy: +and3rson

___
Python tracker 

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

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

[Natal Ngétal]

Natal Ngétal  added the comment:

Please can you convert your patch to a pull request on github.

--
nosy: +hobbestigrou

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[tzickel]

tzickel  added the comment:

The previous posts here touch all this subjects:
A. The documentation explicitly says: "When the pool object is garbage 
collected terminate() will be called immediately." (Happened till a code 
refactor 9 years ago introduced this bug).

B. Large amount of code was developed for this technique:
https://github.com/python/cpython/blob/master/Lib/multiprocessing/util.py#L147 
(Till the end of the file almost)

C. The reason I opened this bug was because I was called to see why a long 
running process crashes after a while, and found out it leaked tons of 
subprocesses / pool._cache memory.

D. The quoted code, will currently simply leak each invocation lots of 
subprocesses... 

I too, think we should push for the said fix.

--

___
Python tracker 

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

[issue35390] ctypes not possible to pass NULL c_void_p in structure by reference

[Dan]

New submission from Dan :

I have a C struct 

typedef struct Effect {
void* ptr;
} Effect;

where when I allocate the memory, the void* gets initialized to NULL, and pass 
back a pointer:

Effect* get_effect(){
Effect* pEffect = malloc(sizeof(*pEffect));
pEffect->ptr = NULL;
return pEffect;
}

In Python, I need to call the C function to initialize, and then pass a 
REFERENCE to the pointer to another C function:

from ctypes import cdll, Structure, c_int, c_void_p, addressof, pointer, 
POINTER, c_double, byref
clibptr = cdll.LoadLibrary("libpointers.so")

class Effect(Structure):
_fields_ = [("ptr", POINTER(c_double))]

clibptr.get_effect.restype = POINTER(Effect)
pEffect = clibptr.get_effect()
effect = pEffect.contents
clibptr.print_ptraddress(byref(effect.ptr))

But this prints an error, because effect.ptr is None, so byref(None) fails.
Below is full working code in the case where ptr is instead a double*, where 
there is no problem. 
As far as I can tell, there is no way to pass a c_void_p field by reference, 
which would be very useful!

#include 
#include 

#define PRINT_MSG_2SX(ARG0, ARG1) printf("From C - [%s] (%d) - [%s]:  ARG0: 
[%s], ARG1: 0x%016llX\n", __FILE__, __LINE__, __FUNCTION__, ARG0, (unsigned 
long long)ARG1)

typedef struct Effect {
double* ptr;
} Effect;

void print_ptraddress(double** ptraddress){
PRINT_MSG_2SX("Address of Pointer:", ptraddress);
}

Effect* get_effect(){
Effect* pEffect = malloc(sizeof(*pEffect));
pEffect->ptr = NULL;
print_ptraddress(>ptr);
return pEffect;
}

Python:

from ctypes import cdll, Structure, c_int, c_void_p, addressof, pointer, 
POINTER, c_double, byref
clibptr = cdll.LoadLibrary("libpointers.so")

class Effect(Structure):
_fields_ = [("ptr", POINTER(c_double))]

clibptr.get_effect.restype = POINTER(Effect)
pEffect = clibptr.get_effect()

effect = pEffect.contents
clibptr.print_ptraddress(byref(effect.ptr))

gives matching addresses:

>From C - [pointers.c] (11) - [print_ptraddress]: ARG0: [Address of Pointer:], 
>ARG1: 0x7FC2E1AD3770 From C - [pointers.c] (11) - [print_ptraddress]: 
>ARG0: [Address of Pointer:], ARG1: 0x7FC2E1AD3770

--
components: ctypes
messages: 330961
nosy: dtamayo
priority: normal
severity: normal
status: open
title: ctypes not possible to pass NULL c_void_p in structure by reference
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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Víctor, I have a PR fixing this in:

issue35378

Even if is not correct to not call close or join on the Pool, this behaviour 
was working before while now it hangs. The fix is really simple, si I think we 
should fix it and not revert the change on this case.

--

___
Python tracker 

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

[issue35368] [2.7] Make PyMem_Malloc() thread-safe in debug mode

[STINNER Victor]

STINNER Victor  added the comment:

According to bpo-31473, the debug hook on PyMem_Malloc() is not thread-safe: 
'serialno' variable is not protected by any lock and it's not atomic.

--

___
Python tracker 

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

[issue35385] time module: why not using tzname from the glibc?

[Paul Ganssle]

Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

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

[issue31473] Debug hooks on memory allocators are not thread safe (serialno variable)

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-35368: [2.7] Make PyMem_Malloc() thread-safe in debug mode.

--

___
Python tracker 

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

[issue31473] Debug hooks on memory allocators are not thread safe (serialno variable)

[STINNER Victor]

Change by STINNER Victor :


--
title: PyMem_Raw* API in debug mode are not thread safe -> Debug hooks on 
memory allocators are not thread safe (serialno variable)
versions: +Python 2.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

[issue31473] PyMem_Raw* API in debug mode are not thread safe

[STINNER Victor]

STINNER Victor  added the comment:

Note: PTHREAD_MUTEX_INITIALIZER can be used to statically initialize a mutex.

--

___
Python tracker 

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

[issue35389] Use gnu_get_libc_version() in platform.libc_ver()?

[STINNER Victor]

STINNER Victor  added the comment:

> >>> os.confstr('CS_GNU_LIBC_VERSION')
> 'glibc 2.28'

That's cool because it doesn't require to write new C code ;-)

--

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[STINNER Victor]

STINNER Victor  added the comment:

"""
def the_test():
print("Begin")
for x in multiprocessing.Pool().imap(int,
["4", "3"]):
print(x)
print("End")
"""

Side-note: Is it correct to use a pool without calling terminate() nor close()? 
Should we start to emit a ResourceWarning if a pool is not closed explicitly, 
as we did for files, sockets, asyncio event loops and subprocess.Popen objects?

--

___
Python tracker 

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

[issue10320] printf %qd is nonstandard

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted

[STINNER Victor]

STINNER Victor  added the comment:

I suggest to revert this change, since it caused a regression: 
"multiprocessing.Pool.imap hangs in MacOs after applying this commit: (...)"

--
nosy: +benjamin.peterson, ned.deily, vstinner
priority: normal -> release blocker
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue35389] Use gnu_get_libc_version() in platform.libc_ver()?

[Jakub Wilk]

Jakub Wilk  added the comment:

You can use confstr to get (running) glibc version:

>>> os.confstr('CS_GNU_LIBC_VERSION')
'glibc 2.28'

--
nosy: +jwilk

___
Python tracker 

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

[issue35389] Use gnu_get_libc_version() in platform.libc_ver()?

[STINNER Victor]

New submission from STINNER Victor :

Currently, platform.libc_ver() opens Python binary file (ex: /usr/bin/python3) 
and looks for a string like "GLIBC-2.28".

Maybe gnu_get_libc_version() should be exposed in Python to get the version of 
the running glibc version? And use it if available, or fall back on parsing the 
binary file (as done currenetly) otherwise.

Example:

$ cat x.c 
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
printf("GNU libc version: %s\n", gnu_get_libc_version());
printf("GNU libc release: %s\n", gnu_get_libc_release());
exit(EXIT_SUCCESS);
}

$ ./x
GNU libc version: 2.28
GNU libc release: stable


I'm not sure if it's possible that Python is compiled with glibc but run with a 
different libc implementation?


--


Alternative: run a program to get the libc version which *might* be different 
than the libc version of Python if the libc is upgraded in the meanwhile 
(unlikely, but is technically possible on a server running for days):

$ ldd --version
ldd (GNU libc) 2.28
...

$ /lib64/libc.so.6 
GNU C Library (GNU libc) stable release version 2.28.
...

$ rpm -q glibc
glibc-2.28-17.fc29.x86_64
...

etc.


--


See also discussions on platform.libc_ver() performance:
https://github.com/python/cpython/pull/10868

--
components: Library (Lib)
messages: 330952
nosy: vstinner
priority: normal
severity: normal
status: open
title: Use gnu_get_libc_version() in platform.libc_ver()?
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

[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals

[Lars Beckers]

Change by Lars Beckers :


--
nosy: +extmind

___
Python tracker 

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

[issue26544] platform.libc_ver() returns incorrect version number

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8687bd86e6f138ef0699a1e9f3f9555765949b51 by Victor Stinner in 
branch '2.7':
bpo-26544: Make platform.libc_ver() less slow (GH-10868)
https://github.com/python/cpython/commit/8687bd86e6f138ef0699a1e9f3f9555765949b51


--

___
Python tracker 

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

[issue35386] ftp://www.pythontest.net/ returns error 500

[STINNER Victor]

STINNER Victor  added the comment:

Ernest w. Durbin iii (EWDurbin) fixed the bug in less than one hour, cool! I 
contacted him on IRC (#python-infra).

The disk was full (/dev/vda1  25G  25G  0 100% /) and cron was stopped.

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

[issue31473] PyMem_Raw* API in debug mode are not thread safe

[STINNER Victor]

STINNER Victor  added the comment:

By the way, the previous attempt to add _PyRuntime.mem had to be reverted. See 
bpo-32096, bpo-30860 and the commit:

commit 9e87e7776f7ace66baaf7247233afdabd00c2b44
Author: Victor Stinner 
Date:   Fri Nov 24 12:09:24 2017 +0100

bpo-32096: Remove obj and mem from _PyRuntime (#4532)

bpo-32096, bpo-30860:  Partially revert the commit
2ebc5ce42a8a9e047e790aefbf9a94811569b2b6:

* Move structures back from Include/internal/mem.h to
  Objects/obmalloc.c
* Remove _PyObject_Initialize() and _PyMem_Initialize()
* Remove Include/internal/pymalloc.h
* Add test_capi.test_pre_initialization_api():
   Make sure that it's possible to call Py_DecodeLocale(), and then call
   Py_SetProgramName() with the decoded string, before Py_Initialize().

PyMem_RawMalloc() and Py_DecodeLocale() can be called again before
_PyRuntimeState_Init().

Co-Authored-By: Eric Snow 

--

___
Python tracker 

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

[issue31473] PyMem_Raw* API in debug mode are not thread safe

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-35265: "Internal C API: pass the memory allocator in a context".

The most complex part is the Python initialization which changes the memory 
allocator *and* allocate memory. We have to remain which allocator has been 
used to allocate data, to be able to release memory at exit.

--

___
Python tracker 

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

[issue31473] PyMem_Raw* API in debug mode are not thread safe

[STINNER Victor]

STINNER Victor  added the comment:

I looked at _Py_atomic_address to avoid atomic "serialno++", but we don't have 
atomic_fetch_add(). We could implement it using a loop and 
atomic_compare_exchange_strong()... but we don't have 
atomic_compare_exchange_strong() neither.

I tried to add a mutex, but there are some pratical issues:

* bpo-35388: question about calling Py_Initialize() / Py_Finalize() multiple 
times
* I modified _PyRuntimeState_Init() to initialize the lock.

_PyRuntimeState_Init() calls PyThread_acquire_lock() which calls 
PyMem_RawMalloc(). Problem: PyMem_RawMalloc() requires the lock. I worked 
around the isuse using "if (_PyRuntime.mem.mutex != NULL) {".

--

___
Python tracker 

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

[issue35388] _PyRuntime_Initialize() called after Py_Finalize() does nothing

[STINNER Victor]

New submission from STINNER Victor :

When Python is embedded, it should be possible to call the following Python 
function multiple times:

void func(void)
{
  Py_Initialize();
  /* do something in Python */
  Py_Finalize();
}

Py_Finalize() ends by calling _PyRuntime_Finalize().

Problem: when Py_Initialize() is called the second time, 
_PyRuntime_Initialize() does nothing:

_PyInitError
_PyRuntime_Initialize(void)
{
/* XXX We only initialize once in the process, which aligns with
   the static initialization of the former globals now found in
   _PyRuntime.  However, _PyRuntime *should* be initialized with
   every Py_Initialize() call, but doing so breaks the runtime.
   This is because the runtime state is not properly finalized
   currently. */
static int initialized = 0;
if (initialized) {
return _Py_INIT_OK();
}
initialized = 1;

return _PyRuntimeState_Init(&_PyRuntime);
}

For example, Py_Finalize() clears runtime->interpreters.mutex and 
runtime->xidregistry.mutex, whereas mutexes are still needed the second time 
func() is called.

There is currently a *workaround*:

_PyInitError
_PyInterpreterState_Enable(_PyRuntimeState *runtime)
{
...
if (runtime->interpreters.mutex == NULL) {
...
runtime->interpreters.mutex = PyThread_allocate_lock();
...
}
...
}

I would prefer that _PyRuntime_Initialize() calls _PyRuntimeState_Init() each 
time, and that _PyRuntimeState_Init() does nothing at the following call 
(except after Py_Finalize?).

Note: _PyRuntimeState_Fini() doesn't free runtime->xidregistry.mutex currently.

--
messages: 330946
nosy: vstinner
priority: normal
severity: normal
status: open
title: _PyRuntime_Initialize() called after Py_Finalize() does nothing
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

[issue35351] LTOFLAGS are passed to BASECFLAGS when using LTO

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue35387] Dialogs on IDLE are accompanied by a small black window

[Kevin Walzer]

New submission from Kevin Walzer :

The "About IDLE" and "Preferences" dialogs on IDLE are accompanied by a small 
black window titled "idle" when IDLE is run agains the tip of Tk 8.6 on macOS 
10.14. This is likely owing to the multiple changes in Tk to accommodate the 
Mac's API changes on Mojave. I suspect the dialog's [wm transient] 
implementation is part of the issue; the parent windows for the dialog are not 
hidden when run against the Tk tip, and thus they have this ugly display. 
Hopefully the fix is not too complicated.

--
assignee: terry.reedy
components: IDLE
messages: 330945
nosy: terry.reedy, wordtech
priority: normal
severity: normal
status: open
title: Dialogs on IDLE are accompanied by a small black window
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

[issue35385] time module: why not using tzname from the glibc?

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

See #28108 and https://sourceware.org/bugzilla/show_bug.cgi?id=23859 (for 
msg276123).

--
nosy: +izbyshev

___
Python tracker 

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

[issue35346] Modernize Lib/platform.py code

[STINNER Victor]

STINNER Victor  added the comment:

Another issue with Python 2 compatibility (I addition to platform.dist() 
removal) of Lib/platform.py from master: it uses re.ASCII which doesn't exist 
in Python 2.7.

--

___
Python tracker 

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

[issue26544] platform.libc_ver() returns incorrect version number

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +10104

___
Python tracker 

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

[issue35373] PyInit_timezone() must return a value

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 3bb150d8148e3cc08418077a58f43e064b9fde61 by Victor Stinner in 
branch 'master':
bpo-35373: Fix PyInit_time() error handling (GH-10865)
https://github.com/python/cpython/commit/3bb150d8148e3cc08418077a58f43e064b9fde61


--

___
Python tracker 

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