[issue39943] Meta: Clean up various issues in C internals

[Andy Lester]

Andy Lester  added the comment:

I'm assuming that you're getting this sre_lib.h error when compiling 
Modules/_sre.c.

--

___
Python tracker 

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

[issue40281] Add pathlib.PurePath.as_uri()

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
nosy: +pablogsal

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[STINNER Victor]

STINNER Victor  added the comment:

Ok, the issue is now fixed: thanks Jeffrey Quesnelle!

> Nope, this was introduced in 3.8

I tested: attached main.c doesn't crash in 3.7. I guess that _asyncio leaks a 
few references, but it's not a big deal.

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[Jeffrey Quesnelle]

Jeffrey Quesnelle  added the comment:

> Is Python 3.7 affected as well?

Nope, this was introduced in 3.8

--

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[STINNER Victor]

STINNER Victor  added the comment:

Is Python 3.7 affected as well?

--

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[miss-islington]

miss-islington  added the comment:


New changeset 6b0ca0aeab04d7b7b54086248ca9d5e70f770f2f by Miss Islington (bot) 
in branch '3.8':
bpo-40294: Fix _asyncio when module is loaded/unloaded multiple times (GH-19542)
https://github.com/python/cpython/commit/6b0ca0aeab04d7b7b54086248ca9d5e70f770f2f


--

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[STINNER Victor]

STINNER Victor  added the comment:

> Would the simple fix (clearing the flag in `module_free`) be a candidate for 
> a backport to 3.8?

Sure.

--

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18907
pull_request: https://github.com/python/cpython/pull/19565

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[STINNER Victor]

STINNER Victor  added the comment:


New changeset a75e730075cd25be1143e6183006f3b1d61bb80f by Jeffrey Quesnelle in 
branch 'master':
bpo-40294: Fix _asyncio when module is loaded/unloaded multiple times (GH-19542)
https://github.com/python/cpython/commit/a75e730075cd25be1143e6183006f3b1d61bb80f


--

___
Python tracker 

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

[issue40288] atexit module should not be loaded more than once per interpreter

[Dong-hee Na]

Change by Dong-hee Na :


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

___
Python tracker 

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

[issue40236] datetime.datetime.strptime get day error

[Paul Ganssle]

Change by Paul Ganssle :


--
stage:  -> needs patch

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

STINNER Victor  added the comment:

This issue has been discussed during the Language Summit. A quick poll showed 
that the majority is in favor of changing the default in Python 3.9.

Lukasz proposed a PEP update to propose to switch the default in Python 3.9:
https://github.com/python/peps/pull/1371/

For me, the unclear part is which projects would be impacted if the default 
changes?

Someone mentioned attrs, but it seems like attrs is fine:
https://github.com/python-attrs/attrs/issues/288#issuecomment-587265961

In term of workflow, I would _prefer_ to get such incompatible in the very 
beginning of a devcycle, rather than just before the feature freeze. But I 
don't think that it's a blocker issue. Technically, changes are allowed until 
3.9.0 beta1. Moreover, Lukasz is the 3.9 release manager, the author of the PEP 
563 and he is in favor of changing the default in 3.9 :-)

--

___
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

[Brett Cannon]

Brett Cannon  added the comment:

I personally like 3.10 as the target as that means users had at least 3 years 
to move to move over. Plus we can put a warning in the What's New for 3.9 about 
our plans for 3.10.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue40223] Add -fwrapv for new icc versions

[Furkan Onder]

Change by Furkan Onder :


--
keywords: +patch
nosy: +furkanonder
nosy_count: 1.0 -> 2.0
pull_requests: +18905
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19561

___
Python tracker 

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

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

[Batuhan Taskaya]

Change by Batuhan Taskaya :


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

[issue38580] select()'s documentation claims only sequences are accepted, but it allows all iterables

[Tal Einat]

Tal Einat  added the comment:

It seems that select() does indeed support arbitrary iterables through the use 
of PySequence_Fast().

The commit where this was introduced, by Brett Cannon from 2003 
(62dba4c2775adfb5a5a97ca012a3ab00c4e28597), doesn't seems to have intended this 
though: "select.select() now accepts a sequence (as defined by 
PySequence_Fast()) for its first three arguments."

However, regardless of whether this is intentional, it appears that this has 
been this way for a very long time. So it seems to me that we should document 
this behavior, as suggested here, since any change to this would be an 
unacceptable backwards-incompatibility.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, taleinat

___
Python tracker 

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

[issue40307] multiprocessing.BaseManager does not retain Client type.

[Alessandro Molina]

Alessandro Molina  added the comment:

The issue seems fairly easy to fix, it's just a matter in consistency in usage 
of self._Client attribute in the manager. I'm working on a PR that I'm willing 
to propose for review once I have finished it and wrote tests.

--

___
Python tracker 

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

[issue40308] Intermittent failure of test_os.TestScandir.test_attributes on Windows

[Dennis Sweeney]

New submission from Dennis Sweeney :

I get the following intermittent failure when running the tests on Master on 
Windows 10.

=
=
=


PS C:\...\cpython> .\python.bat -m unittest -v 
test.test_os.TestScandir.test_attributes
Running Release|Win32 interpreter...
test_attributes (test.test_os.TestScandir) ... ok

--
Ran 1 test in 0.005s

OK
PS C:\...\cpython> .\python.bat -m unittest -v 
test.test_os.TestScandir.test_attributes
Running Release|Win32 interpreter...
test_attributes (test.test_os.TestScandir) ... FAIL

==
FAIL: test_attributes (test.test_os.TestScandir)
--
Traceback (most recent call last):
  File "C:\...\cpython\lib\test\test_os.py", line 3900, in test_attributes
self.check_entry(entry, 'link_file.txt', False, True, False)
  File "C:\...\cpython\lib\test\test_os.py", line 3861, in check_entry
self.assert_stat_equal(entry.stat(),
  File "C:\...\cpython\lib\test\test_os.py", line 3822, in assert_stat_equal
self.assertEqual(getattr(stat1, attr),
AssertionError: 1587065935.7958326 != 1587065935.79683 : 
(os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, 
st_gid=0, st_size=6, st_atime=1587065935, st_mtime=1587065935, 
st_ctime=1587065935), os.stat_result(st_mode=33206, st_ino=2533274791602992, 
st_dev=839545721, st_nlink=2, st_uid=0, st_gid=0, st_size=6, 
st_atime=1587065935, st_mtime=1587065935, st_ctime=1587065935), 'st_atime')

--
Ran 1 test in 0.007s

FAILED (failures=1)

=
=
=


The failure seems to happen only about one in every 3 or 4 runs. Maybe this is 
unrelated, but I'm a little confused about why the repr of os.stat_result makes 
it look like st_atime is an int, but when accessing with .st_atime, we get a 
float that seems to just be st_atime_ns * 10**-9. I ran pdb during the failing 
test and got this:


=
=
=

-> self.assertEqual(getattr(stat1, attr),
(Pdb) stat1
os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, 
st_gid=0, st_size=6, st_atime=1587071882, st_mtime=1587071882, 
st_ctime=1587071882)
(Pdb) stat1
os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, 
st_gid=0, st_size=6, st_atime=1587071882, st_mtime=1587071882, 
st_ctime=1587071882)
(Pdb) stat1.st_atime == stat2.st_atime
False
(Pdb) stat1.st_atime
1587071882.6492443
(Pdb) stat2.st_atime
1587071882.6502416
(Pdb) stat1.st_atime_ns
1587071882649244400
(Pdb) stat2.st_atime_ns
1587071882650241700
(Pdb) dir(stat1)
['__add__', '__class__', '__class_getitem__', '__contains__', '__delattr__', 
'__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', 
'__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__module__', 
'__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 
'count', 'index', 'n_fields', 'n_sequence_fields', 'n_unnamed_fields', 
'st_atime', 'st_atime_ns', 'st_ctime', 'st_ctime_ns', 'st_dev', 
'st_file_attributes', 'st_gid', 'st_ino', 'st_mode', 'st_mtime', 'st_mtime_ns', 
'st_nlink', 'st_reparse_tag', 'st_size', 'st_uid']
(Pdb) dir(stat2)
['__add__', '__class__', '__class_getitem__', '__contains__', '__delattr__', 
'__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', 
'__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__module__', 
'__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__rmul__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 
'count', 'index', 'n_fields', 'n_sequence_fields', 'n_unnamed_fields', 
'st_atime', 'st_atime_ns', 'st_ctime', 'st_ctime_ns', 'st_dev', 
'st_file_attributes', 'st_gid', 'st_ino', 'st_mode', 'st_mtime', 'st_mtime_ns', 
'st_nlink', 'st_reparse_tag', 'st_size', 'st_uid']
(Pdb) tuple(stat1)
(33206, 0, 0, 0, 0, 0, 6, 1587071882, 1587071882, 1587071882)
(Pdb) tuple(stat2)
(33206, 9851624185502411, 839545721, 2, 0, 0, 6, 1587071882, 1587071882, 
1587071882)
(Pdb)

=
=
=

--
components: Windows
messages: 366631
nosy: Dennis Sweeney, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Intermittent failure of test_os.TestScandir.test_attributes on Windows
type: behavior
versions: Python 

[issue40307] multiprocessing.BaseManager does not retain Client type.

[Alessandro Molina]

New submission from Alessandro Molina :

When a new `multiprocessing.managers.BaseManager` instance is made, the client 
used to connect is not stable across the life of the object.

A very quick example to show that is 

```
from unittest.mock import Mock
from multiprocessing.managers import SyncManager, listener_client

listener_client["faked"] = listener_client["xmlrpclib"] 
sm = SyncManager(serializer="faked")
```

As expected the manager is created with the XmlClient

```
>>> print(sm._Client.__name__)
XmlClient
```

but in reality, if the "faked" serializer is changed in any way

```
listener_client["faked"] = (None, Mock(side_effect=RuntimeError("BROKEN")))
```

When trying to connect, we will unexpectedly connect with whatever it is the 
serializer registered at the time of connection instead of the one bound to the 
SyncManager instance 

```
>>> sm.connect()
Traceback (most recent call last):
  File "/home/amol/wrk/cpython/prova.py", line 17, in 
sm.connect()
  File "/home/amol/wrk/cpython/Lib/multiprocessing/managers.py", line 521, in 
connect
conn = Client(self._address, authkey=self._authkey)
  ...
  File "/home/amol/wrk/cpython/Lib/unittest/mock.py", line 1152, in 
_execute_mock_call
raise effect
RuntimeError: BROKEN
```

To make things worse, we would actually randomly use XmlClient or new one 
depending on which SyncManager method we call.

This makes also inconvenient to replace the connection layer with a fake one 
during tests to simulate stub responses. Furthermore the client of the manager 
is also not propagated properly to the proxies created through that manager 
making even less consistent the behaviour.

--
components: Library (Lib)
messages: 366630
nosy: Alessandro Molina
priority: normal
severity: normal
status: open
title: multiprocessing.BaseManager does not retain Client type.
type: behavior
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

[issue40255] Fixing Copy on Writes from reference counting

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> immutability vs immutable object headers

Sorry, I meant to write "immortal vs immutable".

--

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Neil Schemenauer]

Neil Schemenauer  added the comment:

A few thoughts

First, the PR is well done.  The changes are pretty minimal and are well 
localized.  Thanks Eddie for writing clean code and responding to review 
requests.

My feeling is that, in current state, this still should not get merged or at 
least not get enabled by default.  The main consideration is what is the cost 
of this new feature vs what is the benefit.

If the immortalize heap function is not called by default, all Python users pay 
a performance hit for this feature.  Even after recent PR improvements, if you 
don't immortalize the heap, Python is slower. 

Only a small fraction of Python users will benefit from this feature.  I think 
the "pre-fork, CoW exploiting" application architecture is more common than 
some people would realize (it is a successful way to achieve multi-processing 
with CPython, making good use of multiple CPU cores).  However, I'm pretty sure 
it is used by a very tiny fraction of all Python programs.

If we do immortalize by default (e.g. on Python startup), the semantics of the 
refcnt field are subtly changed.  I suspect some programs will be broken as a 
result of this change.  A clue about what might go wrong comes from the unicode 
object code.  E.g. the resize_inplace() function in unicodeobject.c.  It is 
possible that a non-trivial amount of other 3rd party code will make 
assumptions about refcnt that will be broken by this change.  That code could 
be fixed but it is a matter of cost vs benefit.

If it is disabled by default with a build flag we have an ABI compatibility 
problem.  I.e. incref/decref are inlined functions/macros.  Also, as mentioned 
above, these kinds of build options tend to make maintenance and testing harder.

The frozen GC generation did not have these kinds of issues.  If people don't 
use it, there is basically no cost.  I think it was a good idea to merge the 
frozen generation feature.  There is a small amount of ongoing maintenance cost 
but that's acceptable.

Regarding Mark's comment about immutability vs immutable object headers, I 
would frame the goal of the PR differently.  Like the GC frozen generation, 
this immutable instance change is about providing a way to opt-out of Python's 
default garbage collection mechanism.  The frozen generation was to opt-out of 
the mark-and-sweep style cyclic collection.  This PR is about opting-out of the 
default Python reference counting.  

Put that way, could we consider this PR as an incremental step in a process of 
making it possible to have a non-reference count based GC for CPython?  E.g. 
perhaps we could eventually have a mixture of mark-and-sweep and reference 
counted GC, in order to support the handle (HPy) API.  If we want to move 
towards that, we want CPython code to stop making assumptions about the refcnt 
field, like the unicodeobject.c file currently does.

I think pitching the PR in that way makes it more compelling.  Merge it not 
because it helps a tiny class of Python applications.  Instead, merge it 
because it helps find unwarranted assumptions about how the Python GC works.  
Once we get bad assumptions cleaned up in 3rd party code, we have more of 
chance of pursuing an alternative GC strategy for CPython.

--

___
Python tracker 

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

[issue15904] file,close() can fail assert on Windows in 2.7

[Benjamin Peterson]

Change by Benjamin Peterson :


--
resolution:  -> wont fix
stage: needs patch -> 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

[issue40303] argparse parse_args args parameter bug or intended

[paul j3]

paul j3  added the comment:

'type=bool' doesn't get any special treatment.  'bool' is a builtin Python 
function.

test with 

def mybool(astr):
print("mybool:", astr, len(astr), bool(astr))
return bool(astr)

The trick to getting a False value is to pass a genuinely empty string.

As can be seen in several previous bug/issues, 'bool' is allowed as a type 
function, but since the only string that returns False is the empty one, it 
isn't very useful.  And we've resisted attempts give it some special treatment.

Users can write their own 'type' function that accepts language specific 
'true/false' words.  Otherwise we encourage the use of 'store_true', 
'store_false' action values.

--

___
Python tracker 

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

[issue40303] argparse parse_args args parameter bug or intended

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

Hi Gharg, this is expected, both because your program would not actually 
receive `--boolean=''` but `--boolean=`:

➜  ~ cat test.py
import sys

print(sys.argv)
➜  ~ python test.py --boolean=''
['test.py', '--boolean=']

and the way the type argument works. 

You can do what you are looking for by using:

➜  ~ cat test.py
import argparse

parser = argparse.ArgumentParser()
parser.add_argument('--boolean', action='store_const', const=True, 
default=False)

print(parser.parse_args())
➜  ~ python test.py --boolean
Namespace(boolean=True)
➜  ~ python test.py
Namespace(boolean=False)

--
nosy: +remi.lapeyre

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Eddie Elizondo]

Eddie Elizondo  added the comment:

> which would potentially save the two word per object overhead

Btw, I misread. I thought `gc_bits` referred to the bits used by the GC in the 
reference count. In any case, you can still use a bit in the reference count :)

--

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Eddie Elizondo]

Eddie Elizondo  added the comment:

> I'm somewhat puzzled how a version that does no more work and has no jumps is 
> slower.

Oh I think I know why there's some confusion. I've updated the PR from the 
initial version (which is probably the one that you saw). The branching does 
less work in Py_INCREF and Py_DECREF for all instances marked with the immortal 
bit by exiting early.

In the latest change, I added the immortal bit to a bunch of "known" immortal 
objects by. For instance:
* All static types (i.e: PyType_Type, etc.)
* All small ints (-5 to 256)
* The following Singletons: PyTrue, PyFalse, PyNone
* And the heap after the runtime is initialized (in pymain_main)

Example 1)
```
PyObject _Py_NoneStruct = {
  _PyObject_EXTRA_INIT
  1, &_PyNone_Type
#ifdef Py_IMMORTAL_OBJECTS
  _Py_IMMORTAL_BIT,
#else
  1,
#endif  /* Py_IMMORTAL_OBJECTS */
  &_PyNone_Type
};
```

Example 2)
```
static int
pymain_main(_PyArgv *args)
{
PyStatus status = pymain_init(args);
if (_PyStatus_IS_EXIT(status)) {
pymain_free();
return status.exitcode;
}
if (_PyStatus_EXCEPTION(status)) {
pymain_exit_error(status);
}

#ifdef Py_IMMORTAL_OBJECTS
/* Most of the objects alive at this point will stay alive throughout the
 * lifecycle of the runtime. Immortalize to avoid the GC and refcnt costs */
_PyGC_ImmortalizeHeap();
#endif  /* Py_IMMORTAL_OBJECTS */
return Py_RunMain();
```


Therefore, you are now making Py_INCREF and Py_DECREF cheaper for things like  
`Py_RETURN_NONE` and a bunch of other instances.

Let me know if that explains it! I could also send you patch of the branch-less 
version so you can compare them.



> but making the object header immutable prevents changes like

Why would it prevent it? These changes are not mutually exclusive, you can 
still have an immortal bit by:
1) Using a bit from `gc_bits`. Currently you only need 2 bits for the GC. Even 
with a `short` you'll have space for the immortal bit.
2) Using a bit from the ob_refcnt. Separately, using this allows us to 
experiment with a branch-less and test-less code by using saturated adds. For 
example:

```
/* Branch-less incref with saturated add */
#define PY_REFCNT_MAX ((int)(((int)-1)>>1))
#define _Py_INCREF(op) ({
__asm__ (
"addl $0x1, %[refcnt]"
"cmovol  %[refcnt_max], %[refcnt]"
: [refcnt] "+r" (((PyObject *)op)->ob_refcnt)
: [refcnt_max] "r" (PY_REFCNT_MAX)
);})
```

--

___
Python tracker 

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

[issue40303] argparse parse_args args parameter bug or intended

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +paul.j3, rhettinger

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Mark Shannon]

Mark Shannon  added the comment:

Do you have more details on your comparison?
I'm somewhat puzzled how a version that does no more work and has no jumps is 
slower.

The memory hit is not immediate, but making the object header immutable 
prevents changes like 
https://github.com/markshannon/cpython/commit/c73407e7b5d1a0fc794d55c6bcc91cfdc958f6c4
which would potentially save the two word per object overhead that the cyclic 
GC currently imposes.

--

___
Python tracker 

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

[issue40306] Enhancement request for SSLContext - flag to handle trailing dot in hostname

[Christian Heimes]

Christian Heimes  added the comment:

I prefer not to interfere with hostname matching. Could you please open a 
feature request with OpenSSL and request a verification flag to ignore trailing 
dot? I'm happy to expose the feature if OpenSSL implements it.

--

___
Python tracker 

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

[issue40306] Enhancement request for SSLContext - flag to handle trailing dot in hostname

[bli2020]

bli2020  added the comment:

sure, that sounds reasonable. I will open up a feature request with OpenSSL

--

___
Python tracker 

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

[issue40306] Enhancement request for SSLContext - flag to handle trailing dot in hostname

[bli2020]

New submission from bli2020 :

Issue31997 I know this issue was previously closed 
https://bugs.python.org/issue31997 because "it works as expected and should be 
handled in the application layer". But, could the team add a flag in SSLContext 
which will handle the trailing dot hostname appropriately (for the hostname 
check, since openssl does not support trailing dots in the hostname).

Previously in 2.7 and 3.6/before I was able to override ssl.match_hostname to 
add some extra checks, but now I am unable to do so because openssl is used 
instead. This extra flag/implementation would help solve this problem.

--
assignee: christian.heimes
components: SSL
messages: 366620
nosy: bli2020, christian.heimes
priority: normal
severity: normal
status: open
title: Enhancement request for SSLContext - flag to handle trailing dot in 
hostname
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

[issue40305] Fix server_close() method for ThreadingHTTPServer and TCPServer class

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +18903
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19556

___
Python tracker 

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

[issue40305] Fix server_close() method for ThreadingHTTPServer and TCPServer class

[ROUX antoine]

New submission from ROUX antoine :

Maybe : 

Main problem is currently ThreadingHTTPServer which extends 
socketserver.ThreadingMixIn and HTTPServer don't overload his server_close() 
method. This method server_close is defined into both parent class and should 
be both call in implementation to avoid shadow definition.

Second and linked to first problem is the class socketserver.TCPServer which is 
parent class of HTTPServer and extend of BaseServer don't overload method 
server_close() properly indeed this overload call self.socket.close() but 
should also call super().shutdown() to avoid infinite thread join into 
ThreadingHTTPServer server_close() method.

Open to advice

--
components: Library (Lib)
files: testHttpServer.py
messages: 366619
nosy: ROUX antoine2
priority: normal
severity: normal
status: open
title: Fix server_close() method for ThreadingHTTPServer and TCPServer class
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49068/testHttpServer.py

___
Python tracker 

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

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

[A.M. Kuchling]

A.M. Kuchling  added the comment:


New changeset cd09d7e55d160edc454763d3fb6a48180988741a by Miss Islington (bot) 
in branch '3.7':
bpo-39793: use the same domain on make_msgid tests (GH-18698) (GH-19555)
https://github.com/python/cpython/commit/cd09d7e55d160edc454763d3fb6a48180988741a


--

___
Python tracker 

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

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

[A.M. Kuchling]

A.M. Kuchling  added the comment:


New changeset ccf30e96d4bdcf04396e00899a0319041144509f by Miss Islington (bot) 
in branch '3.8':
bpo-39793: use the same domain on make_msgid tests (GH-18698) (GH-19554)
https://github.com/python/cpython/commit/ccf30e96d4bdcf04396e00899a0319041144509f


--

___
Python tracker 

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

[issue15904] file,close() can fail assert on Windows in 2.7

[Zackery Spytz]

Zackery Spytz  added the comment:

Python 2 is EOL.

--
nosy: +ZackerySpytz

___
Python tracker 

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

[issue40299] os.dup seems broken with execvp (LINUX)

[krsna]

krsna  added the comment:

Closing has behavior is documented "The file descriptor created by "os.dup" is 
not inherited by child processes by default since Python 3.4.
https://docs.python.org/3/library/os.html#os.dup;

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

[issue40299] os.dup seems broken with execvp (LINUX)

[krsna]

krsna  added the comment:

I should read the updated documentation changes to modules more often. Adding 
the inheritable works and yes I tested with `os.dup2` which seemed consistent 
with C's dups2. I still think it is quite odd that the low level `dup` function 
has a different behavior than one would expect.

Thank you for you helpful and quick reply Martin.

This may be closed as it is a documented, imo, misbehavior.

On Thursday, April 16, 2020, 12:13:58 AM HST, Martin Panter 
 wrote: 

Martin Panter  added the comment:

The file descriptor created by "os.dup" is not inherited by child processes by 
default since Python 3.4.
https://docs.python.org/3/library/os.html#os.dup

Does it work if you use "os.set_inheritable" or "os.dup2" (which apparently 
sets it inhertiable by default)?

--
nosy: +martin.panter

___
Python tracker 

___

--

___
Python tracker 

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

[issue40304] Classes created using type() don't need to explicitly inherit from object

[Борис Верховский]

New submission from Борис Верховский :

As far as I can tell, passing `(object,)` and `()` as the `bases` parameter to 
the 3-argument version of type() produces the same result, because classes 
inherit from `object` in Python 3:

>>> type('X', (object,), dict(a=1)).__bases__
(,)
>>> type('X', (), dict(a=1)).__bases__
(,)

I just want to make sure I'm not missing something and update the documentation 
of `type()` to reflect that.

--
assignee: docs@python
components: Documentation
messages: 366613
nosy: boris, docs@python
priority: normal
pull_requests: 18902
severity: normal
status: open
title: Classes created using type() don't need to explicitly inherit from object
type: enhancement
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

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

[A.M. Kuchling]

A.M. Kuchling  added the comment:


New changeset 5565c30f0b25996a0e73477fc0e1e1aced52b926 by Batuhan Taşkaya in 
branch 'master':
bpo-39793: use the same domain on make_msgid tests (#18698)
https://github.com/python/cpython/commit/5565c30f0b25996a0e73477fc0e1e1aced52b926


--
nosy: +akuchling

___
Python tracker 

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

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18900
pull_request: https://github.com/python/cpython/pull/19554

___
Python tracker 

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

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

[miss-islington]

Change by miss-islington :


--
pull_requests: +18901
pull_request: https://github.com/python/cpython/pull/19555

___
Python tracker 

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

[issue40290] Add zscore to statistics.NormalDist

[Raymond Hettinger]

Change by Raymond Hettinger :


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

[issue40290] Add zscore to statistics.NormalDist

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 70f027dd22d6522b777d10c250f951e5e416b93a by Raymond Hettinger in 
branch 'master':
bpo-40290: Add zscore() to statistics.NormalDist. (GH-19547)
https://github.com/python/cpython/commit/70f027dd22d6522b777d10c250f951e5e416b93a


--

___
Python tracker 

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

[issue40302] Add _Py_bswap32() function to pyport.h

[STINNER Victor]

STINNER Victor  added the comment:

We have another function which may be grouped somehow in the same category: 
_Py_bit_length().

--

___
Python tracker 

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

[issue40296] help(list[int]) fails

[Guido van Rossum]

Guido van Rossum  added the comment:

Yeah, I think help() or pydoc needs to special-case this. (Didn't your other PR 
attempt to fix this?)

Note that issubclass(list[int].__class__, type) returns True -- the __class__ 
attribute in this case is taken from __origin__, while type() returns the 
"true" class.

I don't know what to do about __subclasses__ -- I expect we should just let it 
be this way.

--

___
Python tracker 

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

[issue40303] argparse parse_args args parameter bug or intended

[Gharg]

New submission from Gharg :

I have a problem regarding args parameter of ArgumentParser.parse_args.

For example:
-
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--boolean", type=bool)
parsed_args = parser.parse_args(["--boolean=''"])
--

results in parsed_args.boolean evaluate to True.
While i understand why this is happening (inner call of bool("''") evaluates to 
True), i don't know if that is an expected behavior.
If we look from console argument pass perspective with the example altered:
test.py
-
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--boolean", type=bool)
parsed_args = parser.parse_args()
--

If i now call:

python test.py --boolean=""

parsed_args.boolean will evaluate to False.

--
messages: 366608
nosy: Gharg
priority: normal
severity: normal
status: open
title: argparse parse_args args parameter bug or intended
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

[issue40271] Allow shell like paths in

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If add such option to zipfile.is_zipfile(), why not add it to other functions? 
There are many tens or hundreds of functions and methods in the stdlib which 
accept a file path. Adding such option to all of them is not practical. And 
zipfile.is_zipfile() does not look special.

Also, there are other options which you may want to add to 
zipfile.is_zipfile(). What about expandvars()? Or support URIs with the 
file:/// scheme? Or maybe someone want to replace ~ with the project directory 
instead of the home directory.

It is better to provide functions for every tiny feature and combine them as 
you want than add an infinite number of options to all functions.

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If the behavior is obviously wrong (like in issue25054), we can fix it without 
warnings, and even backport the fix to older versions, because we do not expect 
that anybody depends on such weird behavior. If we are going to change the 
behavior, but expect that users can depend on the current behavior, we emit a 
FutureWarning first (and we did it for other changes in re). But this issue is 
the hard one. Before 3.7 we did not know that it is related to issue25054. We 
were not going to change this behavior (at least not in near future). But when 
a fix for issue25054 was written we did see that it is the same issue. We did 
not want to keep a bug in issue25054 few versions more, so we changed the 
behavior in this issue without warnings. It was an exceptional case.

This change was documented, in the module documentation, and in "What's New in 
Python 3.7" (section "Porting to Python 3.7"). If this is not enough we will be 
happy to get help to make it better.

--

___
Python tracker 

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

[issue40301] zipfile module: new feature (two lines of code), useful for test, security and forensics

[Zachary Ware]

Change by Zachary Ware :


--
nosy: +alanmcintyre, serhiy.storchaka, twouters

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Eddie Elizondo]

Eddie Elizondo  added the comment:

Mark:
> You are asking the whole world to take a hit on both performance and memory 
> use.

That's an explicit non-goal. That's why the code was guarded to add as an 
optional compilation mode

This should be added by default if and only if this is a neutral or an 
improvement on performance. Which by the way, the latest perf numbers suggest 
that we are now at perf parity / within error (pending official confirmation 
from running this on speed.python.org machines).

Also, can you expand on how is this a performance hit on memory?


> There is only one reference to copy-on-write in a comment. Yet this issue 
> about making object headers immutable.

The PR summary expands on Copy on Writes. If you think this belongs in-code, 
let me know and I can update the PR.


> then make the obvious improvement of changing the branchy code

That is strictly slower. The current version makes Py_INCREF and Py_DECREF 
cheaper for known immortal instances (i.e the heap after runtime init). This 
skips increasing and decreasing the refcount as well as the refcount check for 
deallocation. Using the proposed branch-less version makes all Py_INCREFs and 
Py_DECREFs more expensive.

I ran a couple of benchmarks with the branch-less version to highlight this:

Branch-less version:
unpack_sequence: Mean +- std dev: 98.2 ns +- 4.9 ns
richards: Mean +- std dev: 130 ms +- 5 ms
fannkuch: Mean +- std dev: 894 ms +- 18 ms


Branch version:
unpack_sequence: Mean +- std dev: 82.7 ns +- 3.9 ns
richards: Mean +- std dev: 123 ms +- 4 ms
fannkuch: Mean +- std dev: 838 ms +- 25 ms


> Immortality has advantages because it allows saturating reference counting 
> and thus smaller object headers, but it is not the same as making the object 
> header immutable.

In its current form, this change is not trying to do a strict immutability of 
the header. We can't guarantee that third-party extensions won't mutate the 
instance. Instead, this change tries to maintain an instance's immutability as 
long as it can.

If the issue is with naming, I can easily rename this to something else :)

--

___
Python tracker 

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

[issue40243] Unicode 3.2 numeric uses decimal_changed instead of numeric_changed

[Cheryl Sabella]

Change by Cheryl Sabella :


--
versions:  -Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Mark Borgerding]

Mark Borgerding  added the comment:

@serhiy.storchaka  Thanks for the link to issue25054 to clarify this change was 
not done solely for aesthetics.
Hopefully that will mollify others like me who find their way to this 
discussion as they try to figure out why their code broke with a new version of 
python.


I wish it had been done in a more staged and overt way, but that is just 
spitting in the wind at this point.


Thanks for all your work, my gripe du jour notwithstanding.

--

___
Python tracker 

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

[issue40302] Add _Py_bswap32() function to pyport.h

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Isn't pyport.h a public header?  IMHO you should put in a private header and 
make it an inline function there.

Here is for example what we do in Arrow:
https://github.com/apache/arrow/blob/master/cpp/src/arrow/util/bit_util.h#L48

--
nosy: +pitrou

___
Python tracker 

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The former implementation was wrong. See issue25054 which contains more obvious 
examples of that bug:

>>> re.sub(r"\b|:+", "-", "a::bc")
'-a-:-bc-'

Not all colons were replaced despite the fact that the pattern matches all 
colons.

--

___
Python tracker 

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

[issue40301] zipfile module: new feature (two lines of code), useful for test, security and forensics

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is a new feature and cannot be added to older versions which are in 
feature-freeze.

Adding the feature to (say) Python 2.7.18 would be inconsistent, because it 
wouldn't exist in 2.7.0 through .17. Likewise for all the other versions before 
3.9.

Personally, this sounds like a nice feature to have, and your use-case sounds 
convincing to me.

--
nosy: +steven.daprano
versions:  -Python 2.7, 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

[issue40302] Add _Py_bswap32() function to pyport.h

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue40302] Add _Py_bswap32() function to pyport.h

[STINNER Victor]

New submission from STINNER Victor :

There are multiple files which have to swap bytes. I propose to add functions 
for that:

* _Py_bswap16(): uint16_t
* _Py_bswap32(): uint32_t
* _Py_bswap64(): uint64_t

--
components: Interpreter Core
messages: 366600
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add _Py_bswap32() function to pyport.h
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

[issue40302] Add _Py_bswap32() function to pyport.h

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue40271] Allow shell like paths in

[Massimo Sala]

Massimo Sala  added the comment:

Gavin, zipfile works on all the operating systems where python runs.
Your request is OS dependent... BSD? linux?

The tilde isn't into the ZIP file specifications.
I have to agree with Serhiy: the correct solution is
os.path.expanduser("~/stuff")

--
nosy: +massimosala

___
Python tracker 

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

[issue40301] zipfile module: new feature (two lines of code), useful for test, security and forensics

[Massimo Sala]

Change by Massimo Sala :


--
title: zipfile module: new feature (two lines of code) -> zipfile module: new 
feature (two lines of code), useful for test, security and forensics

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[hai shi]

Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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

[issue40294] Use-after-free crash if multiple interpreters import asyncio module

[Jeffrey Quesnelle]

Jeffrey Quesnelle  added the comment:

Would the simple fix (clearing the flag in `module_free`) be a candidate for a 
backport to 3.8? This seems to be a regression from the previous stable version 
that also limits the usability of subinterpreters -- `asyncio` is loaded by a 
wide variety of libraries and so in general it's not easy to know that a 
particular subinterpreter hasn't loaded `asyncio`.   However, I concede that 
subinterpreters with variable lifetimes isn't a common use case.

--

___
Python tracker 

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

[issue40301] zipfile module: new feature (two lines of code)

[Massimo Sala]

New submission from Massimo Sala :

module zipfile

Tag "Components": I am not sure "Library (Lib)" is the correct one. If it 
isn't, please fix.

I use python to check zip files against malware.
In these files the are binary blobs outside the ZIP archive.
The malware payload isn't inside the ZIP file structure.
Example: a file "openme.zip" with this content :
[blob from offset 0 to offset 5678] 
[ZIP archive from offset 5679 to end of file]

zipfile already handles this, finding the ZIP structure inside the file.

My change is just to add a new public property, to expose an internal variable: 
the file offset of the ZIP structure.

I know, I am after the code freeze of Python 2.7.18.
But the change is really trivial, see the diff.
I hope you can approve this patch for all the Python versions, also for 2.7, to 
have consistency. For 2.7 this is the last call.

--
components: Library (Lib)
files: py27_zipfile.patch
keywords: patch
messages: 366597
nosy: massimosala
priority: normal
severity: normal
status: open
title: zipfile module: new feature (two lines of code)
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49067/py27_zipfile.patch

___
Python tracker 

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

[issue39953] Let's update ssl error codes

[Michael Felt]

Michael Felt  added the comment:

Checked with latest version - and working as expected. Sorry for the noise.

On 15/04/2020 17:53, SilentGhost wrote:
> SilentGhost  added the comment:
>
> Michael, could you try with the latest fix in 584a3cfda4?
>
> --
> nosy: +SilentGhost
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()

[Mark Borgerding]

Mark Borgerding  added the comment:

So third-party code was knowingly broken to satisfy an aesthetic notion that 
substitution should be more like iteration.

Would not a FutureWarning have been a kinder way to stage this implementation?

A foolish consistency, indeed.

--
nosy: +Mark Borgerding

___
Python tracker 

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

[issue35967] Better platform.processor support

[Jason R. Coombs]

Change by Jason R. Coombs :


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

[issue35967] Better platform.processor support

[Jason R. Coombs]

Jason R. Coombs  added the comment:


New changeset 518835f3354d6672e61c9f52348c1e4a2533ea00 by Jason R. Coombs in 
branch 'master':
bpo-35967 resolve platform.processor late (GH-12239)
https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00


--

___
Python tracker 

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

[issue40255] Fixing Copy on Writes from reference counting

[Mark Shannon]

Mark Shannon  added the comment:

A big -1 to this.

You are asking the whole world to take a hit on both performance and memory 
use, in order to save Instagram memory.

The PR uses the term "immortal" everywhere. There is only one reference to 
copy-on-write in a comment. Yet this issue about making object headers 
immutable.
Immortality and object header immutability are not the same.

If object header immutability is to be a requirement, that needs a PEP.

If it is not requirement, but immortality is, then make the obvious improvement 
of changing the branchy code

if (!(obj->refcnt & IMMORTAL_BIT)) {
   obj->refcnt++;
}

to the branchless

obj->refcnt += ((obj->refcnt _BIT) != 0)

Immortality has advantages because it allows saturating reference counting and 
thus smaller object headers, but it is not the same as making the object header 
immutable.

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue40300] logging.Formatter crashes when default_msec_format is None.

[Mariusz Felisiak]

Change by Mariusz Felisiak :


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

___
Python tracker 

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

[issue30483] urllib.parse.parse_qsl does not handle unicode data properly

[Dmitry Tsirkov]

Dmitry Tsirkov  added the comment:

I have recently stumbled upon this bug, and I can present the example and a 
solution I've used.
The issue happens when we try to parse x-www-form-urlencoded of type bytes:
```
>>> from urllib.parse import urlencode, parse_qs
>>> urlencode([('v', 'ö')])
'v=%C3%B6'
>>> parse_qs('v=%C3%B6')
{'v': ['ö']}
>>> parse_qs(b'v=%C3%B6')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.6/urllib/parse.py", line 669, in parse_qs
encoding=encoding, errors=errors)
  File "/usr/lib64/python3.6/urllib/parse.py", line 722, in parse_qsl
value = _coerce_result(value)
  File "/usr/lib64/python3.6/urllib/parse.py", line 103, in _encode_result
return obj.encode(encoding, errors)
UnicodeEncodeError: 'ascii' codec can't encode character '\xf6' in position 0: 
ordinal not in range(128)
```
This happens in the parse_qsl function because _coerce_result is a synonym of 
_encode_result and is called with default parameter encoding='ascii'. As far as 
I understand, it should be called with the encoding parameter of the parse_qsl 
function:
```
742c742
< name = _coerce_result(name)
---
> name = _coerce_result(name, encoding=encoding, errors=errors)
745c745
< value = _coerce_result(value)
---
> value = _coerce_result(value, encoding=encoding, errors=errors)
```
I am not sure whether I should commit this to the repo and create a pull 
request, as described in the devguide.

--
nosy: +cyrkov

___
Python tracker 

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

[issue40300] logging.Formatter crashes when default_msec_format is None.

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue40209] read_pyfile function refactor in Lib/test/test_unparse.py

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

[issue40299] os.dup seems broken with execvp (LINUX)

[Martin Panter]

Martin Panter  added the comment:

The file descriptor created by "os.dup" is not inherited by child processes by 
default since Python 3.4.
https://docs.python.org/3/library/os.html#os.dup

Does it work if you use "os.set_inheritable" or "os.dup2" (which apparently 
sets it inhertiable by default)?

--
nosy: +martin.panter

___
Python tracker 

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

[issue40209] read_pyfile function refactor in Lib/test/test_unparse.py

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 6a5bf15c71a1c101c28774ae714b58e8a65b130c by Hakan Çelik in branch 
'master':
bpo-40209: Use tokenize.open in test_unparse (GH-19399)
https://github.com/python/cpython/commit/6a5bf15c71a1c101c28774ae714b58e8a65b130c


--
nosy: +pablogsal

___
Python tracker 

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

[issue40300] logging.Formatter crashes when default_msec_format is None.

[Mariusz Felisiak]

New submission from Mariusz Felisiak :

We would like to subclass logging.Formatter with a custom "default_time_format" 
and an empty "default_msec_format". Unfortunately logging.Formatter crashes 
when default_msec_format is None, see [1].

I'm happy to provide a patch.

[1] 
https://github.com/python/cpython/blob/5907e61a8d4da6d0f11bf1062d6d17484560a15e/Lib/logging/__init__.py#L607

--
components: Library (Lib)
messages: 366589
nosy: Mariusz Felisiak
priority: normal
severity: normal
status: open
title: logging.Formatter crashes when default_msec_format is None.
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue40133] Provide additional matchers for unittest.mock

[Chris Withers]

Chris Withers  added the comment:

Agreed, this would be better placed in a third party library.

There's examples out there already, for example, I maintain a library [0] that 
has tools for asserting about complex data structures, including flexible type 
matching [1] and regex string matching [2].

[0] 
https://testfixtures.readthedocs.io/en/latest/comparing.html#the-compare-function
[1] 
https://testfixtures.readthedocs.io/en/latest/comparing.html#comparison-objects
[2] 
https://testfixtures.readthedocs.io/en/latest/comparing.html#string-comparison-objects

Diego, would you be okay if we closed this issue and the accompanying pull 
request?

--

___
Python tracker 

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

[issue40299] os.dup seems broken with execvp (LINUX)

[krsna]

New submission from krsna :

---CODE---
import os
path = "file.txt"
  
fd = os.open(path, os.O_WRONLY) 
  
os.close(1) #STDOUT
os.dup(fd)
pid = os.fork()

if pid == 0:
args = "ls -l".split() 
os.execvp(args[0], args)
else:
os.waitpid(pid, 0)
print('Done from Parent')
--- END CODE ---

Running this with python
```
> python -V
Python 3.8.2
```
I get the following:
```
> echo"" > file.txt && python example.py && cat file.txt 
ls: write error: Bad file descriptor
Done from Parent

```
Running the same with micropython:
```
> echo"">file.txt && micropython me && cat file.txt 
total 76
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Desktop
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Documents
drwxr-xr-x 2 user user  4096 Apr 13 18:22 Downloads
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Music
drwxr-xr-x 2 user user  4096 Apr 12 11:16 Pictures
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Public
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Templates
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Videos
-rw-rw-r-- 1 user user   244 Apr 15 22:02 example.py
Done from Parent
```
With the follow C which is almost a 1:1 to the CODE segment above
```
#include 
#include 
#include 

int main(int argc, const char *argv[])
{
int fd = open("file.txt", O_WRONLY);

close(1);
dup(fd);

if (fork() == 0) {
char *cmd = "ls";
char *argv[3];
argv[0] = "ls";
argv[1] = "-l";
argv[2] = NULL;
execvp(cmd, argv);
} else {
wait(0);
close(fd);

puts("Done from Parent");
}

return 0;
}
```
I get the same output as micropython example above
```
> echo"">file.txt && gcc ccc.c && ./a.out && cat file.txt 
total 76
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Desktop
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Documents
drwxr-xr-x 2 user user  4096 Apr 13 18:22 Downloads
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Music
drwxr-xr-x 2 user user  4096 Apr 12 11:16 Pictures
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Public
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Templates
drwxr-xr-x 2 user user  4096 Apr  5 15:29 Videos
-rwxrwxr-x 1 user user 18904 Apr 15 22:53 a.out
-rw-rw-r-- 1 user user   395 Apr 15 22:50 ccc.c
-rw-rw-r-- 1 user user   244 Apr 15 22:02 example.py
Done from Parent
```
I tried looking around for the code of `dup` in cpython to compare, but could 
only find `dup2.c`.

--
components: Library (Lib)
messages: 366587
nosy: krsna
priority: normal
severity: normal
status: open
title: os.dup seems broken with execvp (LINUX)
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

[issue40133] Provide additional matchers for unittest.mock

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks for the idea. But given the size of the patch and benefit it provides 
for the code I feel it could be a better idea to have it in PyPI and then add 
it to stdlib later once it gathers more feedback and adoption. Adding others 
for more feedback.

--
nosy: +cjw296, lisroach, mariocj89, michael.foord

___
Python tracker 

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

[issue40298] Type annotation objects (Tuple, List, etc.) register as callable()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is not a bug. Tuple is a callable, but calling it raises a TypeError with 
the informative error message.

It does not differ from e.g.

>>> def foo():
... raise TypeError("don't call foo()")
... 
>>> callable(foo)
True
>>> foo()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in foo
TypeError: don't call foo()

--
nosy: +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

[issue40260] modulefinder traceback regression starting on Windows

[Barry Alan Scott]

Barry Alan Scott  added the comment:

I have the fix coded and tested.

I run out of git knowledge to update the PR branch so that I can push the fix.

I'll work on it more later in the day.

--

___
Python tracker 

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

[issue40260] modulefinder traceback regression starting on Windows

[Barry Alan Scott]

Change by Barry Alan Scott :


--
pull_requests: +18895
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19549

___
Python tracker 

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

[issue40093] ThreadPoolExecutor with wait=True shuts down too early

[fireattack]

fireattack  added the comment:

>Yes, you are right. This is a feature of the ThreadPoolExecutor.

So is there any way to make the Executor actually wait and accept new job(s) 
after a while? I tried as_completed(), wait(), none seem to work.

--

___
Python tracker 

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

[issue40296] help(list[int]) fails

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The problem is that isinstance(list[int], type) returns True, but list[int] is 
not actually an instance of type.

>>> isinstance(list[int], type)
True
>>> issubclass(type(list[int]), type)
False
>>> type.__subclasses__(list[int])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: descriptor '__subclasses__' for 'type' objects doesn't apply to a 
'types.GenericAlias' object

--

___
Python tracker 

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

[issue40298] Type annotation objects (Tuple, List, etc.) register as callable()

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, levkivskyi

___
Python tracker 

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

[issue40298] Type annotation objects (Tuple, List, etc.) register as callable()

[Noah May]

New submission from Noah May :

Whether this is considered a bug or not is subjective. The question is should 
callable(Tuple) return True or False? Or should it for any other annotation 
object?

The reason it returns true in the first place is because of a warning to 
explicitly NOT call them as functions/constructors:

>>> from typing import Tuple
>>> callable(Tuple)
True
>>> Tuple()
TypeError: Type Tuple cannot be instantiated; use tuple() instead

Source code: 
https://github.com/python/cpython/blob/master/Lib/typing.py#L724:L733

I honestly don't know how this could be "fixed" if it even needs to be fixed. 
But I just wanted to bring attention to it.

Cheers.

--
components: Library (Lib)
messages: 366580
nosy: Noah May
priority: normal
severity: normal
status: open
title: Type annotation objects (Tuple, List, etc.) register as callable()
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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