[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Petr Viktorin]

Petr Viktorin  added the comment:

I agree with Steve that renaming tp_print to tp_vectorcall_offset is well 
within our rights.

For reference, the rationale for the replacing is the first section of:
   https://mail.python.org/pipermail/python-dev/2018-June/153927.html 
I hope Cython's situation here has not changed. (In that case, we should bring 
tp_print back, and add tp_vectorcall_offset to the end.)


Now, I see the question of bringing tp_print back as a *practical* 
compatibility matter, a workaround for the combination of two unfortunate 
issues:
- Cython sets tp_print in Python 3 (which is a bug, but honestly, the word 
"reserved" could very well be interpreted as "unused" rather than "don't touch 
this" -- and even the post linked above, and by extension PEP 590, implies that 
interpretation!)
- Packages hard-code Cython-generated files (which is a workaround for a 
long-standing setuptools limitation that is only recently being addressed).

If we bring tp_print back, it would be because *we shouldn't punish users* even 
if we can. Nobody did anything wrong, apart from a quite understandable 
bug/misunterstanding.


Note that 3rd party projects *do not* have the whole beta cycle to adapt. Until 
NumPy works, its dependents can't start adapting. (Unless adapting is done 
without PyPI packages, like the Fedora rebuild where we now "re-Cythonize" 
everything.)
On the other hand, 3rd party projects don't really *need* to support 3.8.0 as 
soon as it's released. It's just that if they don't support the betas and RCs, 
we're don't get feedback for them in time.


So I think the question is: Is (the rest of) the beta cycle enough for enough 
of the ecosystem to release new wheels, or should we give them the whole 3.9 
cycle?

I believe 3.8 beta2 is enough, and we don't need to bring tp_print back.

--

___
Python tracker 

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

[issue37319] Deprecate using random.randrange() with non-integers

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Why this code uses int() at all? My guess is that it was added for earlier 
detection of user errors, otherwise the user could get a TypeError or 
AttributeError with unrelated message, or even a wrong result. int() is used 
just for type checking. But it is not good tool for this. int() does several 
different actions:

1. Parses string representation of integer.

2. Converts a real number to an integer with some truncation.

3. Losslessly converts an int-like number into an instance of int.

The first two options are not applicable here, so we need an additional check

if istart != start:
raise ValueError("non-integer arg 1 for randrange()")

And this is not perfect: for randrange('5') we get a ValueError instead of 
expected TypeError.

operator.index() is better tool for this.

--

___
Python tracker 

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

[issue36422] tempfile.TemporaryDirectory() removes entire directory tree even if it's a mount-point

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

I implemented an onerror callback for tempfile.TemporaryDirectory() and 
confirmed that it cannot be used to unmount a mount point.  Attempting to 
unmount the mount point from within the callback results in a resource busy 
error.  It may be related to shutil.rmtree() holding an open file descriptor to 
the parent directory of the mount point.

I uploaded the program I used for testing on macOS (test-mounted-image.py). The 
subprocess.run() calls can be modified to run it on other platforms.

--
Added file: https://bugs.python.org/file48429/test-mounted-image.py

___
Python tracker 

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

[issue36231] Support builds on macOS without installed system header files

[Dmitrii Pasechnik]

Dmitrii Pasechnik  added the comment:

Thanks for the review of our PR. I think not all points made there are relevant:

* on older systems, where `xcrun --show-sdk-path` is not available, one can 
assume that /usr/include is there, and simply set the corresponding variable to 
this value in ./configure

* building Python with a non-system compiler is only possible with system 
headers, and thus either SDK or at least command line tools, available, and all 
is well.

* mid-flight switching to a different SDK/compiler is dodgy, and in particular 
switching to a different set of headers is asking for trouble. And the gcc 
toolchain is not much different in this way - e.g. on Gentoo one can do 
gcc-config to switch from one profile to another, with provably "interesting" 
results if it is done mid-flight.  

* the Python 2.7 zlib issue is not a problem with our PR. 

-

Most probably, the desired switch to autotools can only happen gradually, by 
moving more of setup.py to ./configure, and our PR is a step in such direction.

--

___
Python tracker 

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

[issue37341] str.format and f-string divergence

[Eric V. Smith]

Eric V. Smith  added the comment:

I've fixed the bpo number in Misc/NEWS.d/3.8.0b1.rst. Thanks for reporting that.

--

___
Python tracker 

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

[issue37328] remove deprecated HTMLParser.unescape

[Ezio Melotti]

Change by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue37346] Documentation of os not using OSError subclasses

[Tim Hoffmann]

New submission from Tim Hoffmann :

The documentation of `os` does not use the more specific `OSError` subclasses 
introduced in PEP 3151.

--
assignee: docs@python
components: Documentation
messages: 346110
nosy: docs@python, timhoffm
priority: normal
severity: normal
status: open
title: Documentation of os not using OSError subclasses

___
Python tracker 

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

[issue37339] os.path.ismount returns true on nested btrfs subvolumes

[Eike Fokken]

Eike Fokken  added the comment:

I read the other issue, thanks.

What do you mean by "portable version of mountpoint"? Is there a portable 
version of mountpoint or was it more a figure of speech?

Concerning the issue itself:

What are the priorities with the behaviour of ismount?
Is it more important to be consistent with the system it is run on or is it 
more important that every python instance on every system would return the same 
values?

I see merits for both, I'm just curious what the python developers value more.

In case it is the later I propose to change the docs on ismount again to 
include that it disagrees with Linux on nested btrfs subvolumes.

If you like I can make a pull request for that.
My favourite solution would be to have agreement with linux on this but at the 
moment I have no idea how that could be implemented without resorting to Linux 
native utilities.

--

___
Python tracker 

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

[issue37346] Documentation of os not using OSError subclasses

[Tim Hoffmann]

Change by Tim Hoffmann :


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

___
Python tracker 

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

[issue37345] Add formal support for UDPLITE protococl

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Adding new constants like socket.IPPROTO_UDPLITE is fine.
The question is: why we need a new function?
There is no set_send_checksum_coverage() on C level IIRC

--
nosy: +asvetlov

___
Python tracker 

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

[issue37334] Add a cancel method to asyncio Queues

[Martin Teichmann]

Martin Teichmann  added the comment:

I also thought about `.close()` but then found `.cancel()` more intuitive. But 
intuition is not universal, so I am open to any wording.

--

___
Python tracker 

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

[issue37347] Reference-counting problem in sqlite

[Aleksandr Balezin]

New submission from Aleksandr Balezin :

There are a couple of bugs in sqlite bindings have been found related to 
reference-counting.
Short info:
sqlite connection class uses a dict to keep references to callbacks. This 
mechanism is not suitable for objects which equals but not the same. 
con = sqlite3.connect()
con.set_trace_callback(logger.debug) 
con.set_trace_callback(logger.debug)  # logger.debug == logger.debug is True, 
but logger.debug is logger.debug is False because logger.debug bound method is 
creating in every call
leads to segmentation fault during calling of trace_callback.
My patch fixes this behavior by using a dedicated variable for keeping 
references to each callback and using dict indexed by function name in case of 
named callbacks(e.g. create_function()).
Also, due to keeping objects in a variable or in a dict value, it is possible 
to use unhashable objects as callbacks. e.g. issue7478

Long version:
Sqlite under the hood use dict(called function_pinboard) to keep references to 
callbacks like progress_handler. 
It needs to decref callbacks objects after closing sqlite connection. 
This mechanism works tolerably(see bug with leaks) with functions but if you 
try to use bounded methods it causes a segmentation fault.
Let see how it works.

static PyObject *
Custom_set_callback(CustomObject *self, PyObject* args)
{
PyObject* display_str;
display_str = PyUnicode_FromFormat("set_callback called with cb=%R 
id=%i ob_refcnt=%i\n", args, args, args->ob_refcnt);
PyObject_Print(display_str, stdout, Py_PRINT_RAW);
if (PyDict_SetItem(self->function_pinboard, args, Py_None) == -1) 
return NULL;
//sqlite3_trace(self->db, _trace_callback, trace_callback);
self->callback_handler = args;
display_str = PyUnicode_FromFormat("set_callback done for cb=%R id=%i 
ob_refcnt=%i\n", args, args, args->ob_refcnt);
PyObject_Print(display_str, stdout, Py_PRINT_RAW);
Py_RETURN_NONE;
}
static PyObject *
Custom_call_callback(CustomObject *self)
{
PyObject* display_str;
display_str = PyUnicode_FromFormat("call with id=%i ob_refcnt=%i\n", 
self->callback_handler ,
self->callback_handler->ob_refcnt);
PyObject_Print(display_str, stdout, Py_PRINT_RAW);
Py_RETURN_NONE;
}

Python code:
 class TEST:
def log(self, msg=""):
pass
 t = TEST()
 conn = Custom()
 conn.set_trace_callback(t.log)
set_callback called with cb=> id=196094408 ob_refcnt=1
set_callback done for cb=> id=196094408 ob_refcnt=2
 conn.set_trace_callback(t.log)
set_callback called with cb=> id=196095112 ob_refcnt=1
set_callback done for cb=> id=196095112 ob_refcnt=1
conn.call()
call with id=196095112 ob_refcnt=0

After second conn.set_trace_callback(t.log) call, object t.log reference-count 
is not increased because 't.log in self->function_pinboard' returns True thus 
self->function_pinboard[t.log] is not replaced and t.log is not increfed, but 
it replaces old object in self->callback_handler.
In the end, self->callback_handler keeps a pointer to t.log with ob_refcnt = 0.

Also, there is no cleaning of self->function_pinboard. This leads to leaks 
every object passed as callback(see test_leak() in bug.py).

--
components: Extension Modules
messages: 346114
nosy: gescheit, ghaering
priority: normal
severity: normal
status: open
title: Reference-counting problem in sqlite
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue37347] Reference-counting problem in sqlite

[Aleksandr Balezin]

Change by Aleksandr Balezin :


Added file: https://bugs.python.org/file48430/bug.py

___
Python tracker 

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

[issue37348] add _PyUnicode_FROM_ASCII macro

[Inada Naoki]

Change by Inada Naoki :


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

___
Python tracker 

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

[issue37348] add _PyUnicode_FROM_ASCII macro

[Inada Naoki]

New submission from Inada Naoki :

_PyUnicode_FromASCII(s, len) is faster than PyUnicode_FromString(s) because 
PyUnicode_FromString() uses temporary _PyUnicodeWriter to support UTF-8.

But _PyUnicode_FromASCII("hello", strlen("hello"))` is not as easy as 
`PyUnicode_FromString("hello")`.

_PyUnicode_FROM_ASCII() is simple macro which wraps _PyUnicode_FromASCII which 
calls strlen() automatically:

```
/* Convenient wrapper for _PyUnicode_FromASCII */
#define _PyUnicode_FROM_ASCII(s) _PyUnicode_FromASCII((s), strlen(s))
```

I believe recent compilers optimize away calls of strlen().

--
components: Interpreter Core
messages: 346115
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: add _PyUnicode_FROM_ASCII macro
type: performance
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

[issue37348] add _PyUnicode_FROM_ASCII macro

[STINNER Victor]

STINNER Victor  added the comment:

> #define _PyUnicode_FROM_ASCII(s) _PyUnicode_FromASCII((s), strlen(s))

LGTM.

--
nosy: +vstinner

___
Python tracker 

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

[issue37348] add _PyUnicode_FROM_ASCII macro

[Inada Naoki]

Inada Naoki  added the comment:

I confirmed at least one measurable speedup:

./python -m pyperf timeit -s 'd={}' -- 'repr(d)'

FromString: Mean +- std dev: 157 ns +- 3 ns
FROM_ASCII: Mean +- std dev: 132 ns +- 3 ns

>>> (157-132)/157
0.1592356687898089

--

___
Python tracker 

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

[issue37348] add _PyUnicode_FROM_ASCII macro

[Inada Naoki]

Inada Naoki  added the comment:

Should we make these APIs public?

* rename `_PyUnicode_FromASCII` to `PyUnicode_FromASCIIAndSize`.
* add `PyUnicode_FromASCII` as static inline function (without ABI).
* add `#define _PyUnicode_FromASCII PyUnicode_FromASCIIAndSize` for source code 
compatibility.

--

___
Python tracker 

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

[issue37347] Reference-counting problem in sqlite

[Aleksandr Balezin]

Change by Aleksandr Balezin :


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

___
Python tracker 

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

[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging

[Ben Spiller]

Ben Spiller  added the comment:

I'd definitely suggest we go for a solution that doesn't hit performance of 
normal logging when you're not adding/removing things, being as that's the more 
common case. I guess that's the reason why callHandlers was originally 
implemented without grabbing the mutex, and we should probably keep it that 
way. Logging can be a performance-critical part of some applications and I feel 
more comfortable about the fix (and more confident it won't get vetoed :)) if 
we can avoid changing callHandlers(). 

You make a good point about ensuring the solution works for non-GIL python 
versions. I thought about it some more... correct me if I'm wrong but as far as 
I can see the second idea I suggested should do that, i.e.
- self.handlers.remove(hdlr)
+ newhandlers = list(self.handlers)
+ newhandlers.remove(hdlr)
+ self.handlers = hdlr

... which effectively changes the model so that the _value_ of the 
self.handlers list is immutable (only which list the self.handlers reference 
points to changes), so without relying on any GIL locking callHandlers will 
still see the old list or the new list but never see an inconsistent value, 
since such a list never exists. That solves the read-write race condition; we'd 
still want to keep the existing locking in add/removeHandler which prevents 
write-write race conditions. 

What do you think?

--

___
Python tracker 

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

[issue37337] Add _PyObject_VectorcallMethod() function

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +14093
pull_request: https://github.com/python/cpython/pull/14267

___
Python tracker 

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

[issue37347] Reference-counting problem in sqlite

[Aleksandr Balezin]

Change by Aleksandr Balezin :


--
pull_requests: +14094
pull_request: https://github.com/python/cpython/pull/14268

___
Python tracker 

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

[issue37345] Add formal support for UDPLITE protococl

[Gabe Appleton]

Gabe Appleton  added the comment:

Its true that this doesnt exist at the C level, however I worry that having it 
purely through getsockopt() and setsockopt() would make things more confusing, 
so I added it as a helper function.

I can remove it in lieu of documentation if that would block merging, though I 
dont think that is the right move here.

On June 20, 2019 10:54:58 AM UTC, Andrew Svetlov  wrote:
>
>Andrew Svetlov  added the comment:
>
>Adding new constants like socket.IPPROTO_UDPLITE is fine.
>The question is: why we need a new function?
>There is no set_send_checksum_coverage() on C level IIRC
>
>--
>nosy: +asvetlov
>
>___
>Python tracker 
>
>___

--

___
Python tracker 

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

[issue37348] add _PyUnicode_FROM_ASCII macro

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Most of changes are in not performance sensitive code. I do not think there is 
a benefit of using new macro there.

If PyUnicode_FromString() is slow I prefer to optimize it instead of adding yet 
one esoteric private function for internal needs.

In case of dict.__repr__() we can get even more gain by using _Py_IDENTIFIER or 
more general API proposed by 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

[issue37151] Calling code cleanup after PEP 590

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +14095
pull_request: https://github.com/python/cpython/pull/14269

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

New submission from Caleb Donovick :

Currently EnvBuilder allows for a number of customizations of virtual 
environments, however, it does not allow for any modifications of the activate 
script itself (unless one wants to rewrite it completely).  Yet, it is fairly 
common requirement for python packages is to set some environmental variable 
e.g., DJANGO_SETTINGS_MODULE=.

EnvBuilder should be able extend the set of variables which are set and 
restored on activate / deactivate (or more generally have activate / deactivate 
hooks).

Originally proposed on python-ideas 
https://mail.python.org/archives/list/python-id...@python.org/thread/MJNFEFT4GBVBEETJWZUQM5SS6C34PT3K/

--
components: Interpreter Core
messages: 346122
nosy: donovick
priority: normal
severity: normal
status: open
title: venv.EnvBuilder environmental variable hooks
type: enhancement

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Steve Dower]

Steve Dower  added the comment:

> I was trying to tell you that already in msg345969 but you insisted in 
> msg345988 that we should support that anyway.

I made a general note that "extremely unlikely" isn't unlikely enough to be an 
argument.

You'll notice I didn't quote any of the rest of your specific scenario, because 
I wasn't trying to address it. And in any case, you left out the cross-version 
part in that description, so you did actually describe a supported case.

(I'm not going to argue this particular point any further. If I can't help you 
learn the ways we do decision making on a project like CPython then I'll let 
someone else try.)

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Change by Caleb Donovick :


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

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Caleb Donovick  added the comment:

I have basic version working in POSIX.

--

___
Python tracker 

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

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests:  -13873

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
components: +Library (Lib) -Interpreter Core
nosy: +vinay.sajip
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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Can we then bring back the discussion to the core of this issue: should we 
restore tp_print or not in PyTypeObject?

Note that the PR for the other similar issue #37221 has been accepted for 
merging.

--

___
Python tracker 

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

[issue37151] Calling code cleanup after PEP 590

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 7e1a9aacff95c68d284f31666fe293fa2db5406d by Inada Naoki (Jeroen 
Demeyer) in branch 'master':
bpo-37151: remove _PyCFunction_FastCallDict (GH-14269)
https://github.com/python/cpython/commit/7e1a9aacff95c68d284f31666fe293fa2db5406d


--

___
Python tracker 

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

[issue37342] A type error in typeobj.rst

[hai shi]

Change by hai shi :


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

[issue37348] add _PyUnicode_FROM_ASCII macro

[Inada Naoki]

Change by Inada Naoki :


--
pull_requests: +14097
pull_request: https://github.com/python/cpython/pull/14273

___
Python tracker 

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

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

[Inada Naoki]

Inada Naoki  added the comment:

> Most of changes are in not performance sensitive code. I do not think there 
> is a benefit of using new macro there.

Because I used just sed.

> If PyUnicode_FromString() is slow I prefer to optimize it instead of adding 
> yet one esoteric private function for internal needs.

OK.  There are some code like `PyUnicode_FromString(name)`.  Optimizing 
PyUnicode_FromString will be more effective.  I created PR 14273.


> In case of dict.__repr__() we can get even more gain by using _Py_IDENTIFIER 
> or more general API proposed by Victor.

Of course, I used it just for micro benchmarking.  Optimizing it is not a goal. 
 In case of PR 14273:

$ ./python -m pyperf timeit -s 'd={}' -- 'repr(d)'
.
Mean +- std dev: 138 ns +- 2 ns

--
title: add _PyUnicode_FROM_ASCII macro -> Optimize PyUnicode_GetString for 
short ASCII strings

___
Python tracker 

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

[issue37347] Reference-counting problem in sqlite

[Aleksandr Balezin]

Change by Aleksandr Balezin :


--
pull_requests:  -14092

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Steve Dower]

Steve Dower  added the comment:

> Note that the PR for the other similar issue #37221 has been accepted for 
> merging.

I've already explained why that issue is different (it breaks a compatibility 
guarantee; this one changes something that was explicitly deprecated).

Petr's question seems to be the right one that we have not yet answered:

> Is (the rest of) the beta cycle enough for enough of the ecosystem to release 
> new wheels, or should we give them the whole 3.9 cycle?

(And since the 3.8 RM has not been here to discuss release cycle stuff, let's 
invite him in)

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue37350] print ResourceWarning object traceback when raise as error with -W error

[Thomas Grainger]

New submission from Thomas Grainger :

Current behaviour 

$ cat foo.py
def foo():
open('foo', 'wb')


foo()
$ python3.8 -W all::ResourceWarning -X tracemalloc=5 foo.py
foo.py:2: ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>
  open('foo', 'wb')
Object allocated at (most recent call last):
  File "foo.py", lineno 5
foo()
  File "foo.py", lineno 2
open('foo', 'wb')
$ python3.8 -W error -X tracemalloc=5 foo.py
Exception ignored in: <_io.FileIO name='foo' mode='wb' closefd=True>
ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>

Expected behaviour

# Pastebin Eu0gvZ5Z
$ cat foo.py
def foo():
open('foo', 'wb')


foo()
$ python3.8 -W all::ResourceWarning -X tracemalloc=5 foo.py
foo.py:2: ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>
  open('foo', 'wb')
Object allocated at (most recent call last):
  File "foo.py", lineno 5
foo()
  File "foo.py", lineno 2
open('foo', 'wb')
$ python3.8 -W error -X tracemalloc=5 foo.py
Exception ignored in: <_io.FileIO name='foo' mode='wb' closefd=True>
ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>
  open('foo', 'wb')
Object allocated at (most recent call last):
  File "foo.py", lineno 5
foo()
  File "foo.py", lineno 2
open('foo', 'wb')

--
messages: 346129
nosy: graingert
priority: normal
severity: normal
status: open
title: print ResourceWarning object traceback when raise as error with -W error

___
Python tracker 

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

[issue37350] print ResourceWarning object traceback when raised as error with -W error and -X tracemalloc

[Thomas Grainger]

Change by Thomas Grainger :


--
title: print ResourceWarning object traceback when raise as error with -W error 
-> print ResourceWarning object traceback when raised as error with -W error 
and -X tracemalloc

___
Python tracker 

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

[issue37350] print ResourceWarning object traceback when raised as error with -W error and -X tracemalloc

[STINNER Victor]

STINNER Victor  added the comment:

You can implement this behavior using the new sys.unraisablehook (Python 3.8):
---
import sys
import tracemalloc

def foo():
open('foo', 'wb')

def hook(unraisable):
orig_unraisablehook(unraisable)
if unraisable.object is not None:
tb = tracemalloc.get_object_traceback(unraisable.object)
if tb:
print("Object allocated at:")
for line in tb:
print(line)


orig_unraisablehook = sys.unraisablehook
sys.unraisablehook = hook
tracemalloc.start(5)

foo()
---

Output:
---
Exception ignored in: <_io.FileIO name='foo' mode='wb' closefd=True>
Traceback (most recent call last):
  File "foo.py", line 5, in foo
open('foo', 'wb')
ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>
Object allocated at:
foo.py:21
foo.py:5
---

I understand that this issue is about modifying 
_PyErr_WriteUnraisableDefaultHook() in Python/errors.c (it's written in C) to 
implement the same logic than the default implementation of 
warnings._formatwarnmsg() when formatting a ResourceWarning with the source 
object:

try:
import tracemalloc
# Logging a warning should not raise a new exception:
# catch Exception, not only ImportError and RecursionError.
except Exception:
# don't suggest to enable tracemalloc if it's not available
tracing = True
tb = None
else:
tracing = tracemalloc.is_tracing()
try:
tb = tracemalloc.get_object_traceback(msg.source)
except Exception:
# When a warning is logged during Python shutdown, tracemalloc
# and the import machinery don't work anymore
tb = None

if tb is not None:
s += 'Object allocated at (most recent call last):\n'
for frame in tb:
s += ('  File "%s", lineno %s\n'
  % (frame.filename, frame.lineno))

try:
if linecache is not None:
line = linecache.getline(frame.filename, frame.lineno)
else:
line = None
except Exception:
line = None
if line:
line = line.strip()
s += '%s\n' % line
elif not tracing:
s += (f'{category}: Enable tracemalloc to get the object '
  f'allocation traceback\n')


In C, _PyTraceMalloc_GetTraceback() can be used to retrieve the traceback of an 
object saved by tracemalloc.

See also _PyMem_DumpTraceback() used to log the tracemaltoc when Python detects 
a buffer overflow:
https://pythondev.readthedocs.io/debug_tools.html#debug-memory-errors

--
nosy: +vstinner

___
Python tracker 

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

[issue24772] Smaller viewport shifts the "expand left menu" character into the text

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

@karl If you are still interested in solving this, open a pull request on 
https://github.com/python/cpython

--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue37344] plistlib doesn't skip whitespace in XML format detection

[Prateek Nayak]

Change by Prateek Nayak :


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

___
Python tracker 

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

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

[Inada Naoki]

Inada Naoki  added the comment:

Oh, wait.  Why we used _PyUnicodeWriter here?
Decoding UTF-8 must not require it.  2-pass is enough.

--

___
Python tracker 

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

[issue36511] Add Windows ARM32 buildbot

[Steve Dower]

Steve Dower  added the comment:


New changeset a1952122a3a20272e4db9e3c6205009a91c73ccf by Steve Dower (Paul 
Monson) in branch 'master':
bpo-36511: Improve ARM32 buildbot scripts (GH-14251)
https://github.com/python/cpython/commit/a1952122a3a20272e4db9e3c6205009a91c73ccf


--

___
Python tracker 

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

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

[STINNER Victor]

STINNER Victor  added the comment:

> _PyUnicode_FromASCII(s, len) is faster than PyUnicode_FromString(s) because 
> PyUnicode_FromString() uses temporary _PyUnicodeWriter to support UTF-8.

I don't understand how _PyUnicodeWriter could be slow. It does not overallocate 
by default. It's just wrapper to implement efficient memory management.

> Oh, wait.  Why we used _PyUnicodeWriter here?

To optimize decoding errors: the error handler can use replacement string 
longer than 1 character. Overallocation is used in this case.

--

___
Python tracker 

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

[issue20431] Should posix functions that accept fd also accept objects with .fileno()?

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +vstinner

___
Python tracker 

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

[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging

[Vinay Sajip]

Vinay Sajip  added the comment:

> I'd definitely suggest we go for a solution that doesn't hit performance of 
> normal logging

I agree, but correctness is important. I'm tending to the following:

1. Introduce a lockCallHandling module-level variable, defaulting to False to 
maximise logging performance (and follow current behaviour) and settable to 
True for situations such as your example, where adding/removing handlers from 
threads is wanted.

2. In Logger.handle, add an extra check for lockCallHandling to decide whether 
to lock/release around callHandlers().

BTW a simple benchmark of performance of locking around callHanders vs. not 
locking, using a FileHandler and default StreamHandler, showed an average 
difference of ~ 480 usec per iteration (mean time of 47.310 secs unlocked vs. 
47.784 locked, for a million iterations of logger.debug() - a 1% increase).

> the second idea I suggested should do that

Yes, but the copying seems to make things slower, as suggested by the output of 
your script (in terms of the iteration counts in a fixed amount of time).

--

___
Python tracker 

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

[issue37351] Drop libpython38.a from Windows release

[Steve Dower]

New submission from Steve Dower :

The step of generating a MinGW import library for Python releases is very 
rarely used, forces us to take extra build dependencies, and is better handled 
by the end-users who need it.

We will drop the libpython38.a file from the main distribution, and update the 
docs to contain the commands necessary (users who are using MinGW will have 
these tools easily available):

gendef python38.dll > tmp.def
dlltool --dllname python38.dll --def tmp.def --output-lib libpython38.a

Here is where Anaconda have been doing this themselves, rather than relying on 
our distributed file: 
https://github.com/AnacondaRecipes/aggregate/blob/master/libpython-feedstock/recipe/bld.bat

We also heard that the regex module no longer relies on this: 
https://mail.python.org/archives/list/python-...@python.org/message/A7IXOTARTYJUNSCFAU3YY2VOVILC4EBY/

A few people do regularly use this file, according to 
https://mobile.twitter.com/zooba/status/1139661637521031168 which is why 
including the instructions and porting notes is important. I haven't heard from 
any of them that they would have trouble running the above commands themselves.

--
assignee: steve.dower
components: Windows
messages: 346136
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Drop libpython38.a from Windows release
type: behavior
versions: 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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Terry Davis]

Terry Davis  added the comment:

I'd like to re-raise this issue. Should I cross-post to "discuss.python.org - 
Ideas"?

--
nosy: +Terry Davis

___
Python tracker 

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

[issue37351] Drop libpython38.a from Windows release

[Steve Dower]

Steve Dower  added the comment:

Realising that this may have an impact on 
distutils.cygwincompiler.Mingw32CCompiler, but I can't tell from the source 
code how/whether it would pick up the pre-packaged libpython38.a. Does anyone 
know?

--
components: +Distutils
nosy: +dstufft, eric.araujo

___
Python tracker 

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

[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging

[Ben Spiller]

Ben Spiller  added the comment:

Interesting conversation. :)

Yes I agree correctness is definitely top priority. :) I'd go further and say 
I'd prefer correctness to be always there automatically, rather than something 
the user must remember to enable by setting a flag such as lockCallHandling. 
(as an aside, adding a separate extra code path and option like that would 
require a bit more doc and testing changes than just fixing the bug by making 
the self.handlers list immutable, which is a small and simple change not 
needing extra doc). 

I'm also not convinced it's worth optimizing the performance of add/remove 
logger (which sounds like it's the goal of the callHandlers-locking approach 
you suggest, if I'm understanding correctly?) - since in a realistic 
application is always that's going to be vastly less frequent than invoking 
callhandlers. Especially if it reduces performance of the main logging, which 
is invoked much more often. Though admittedly the 1% regression you quoted 
isn't so bad (assuming that's true in CPython/IronPython/Jython/others). The 
test program I provided is a contrived way of quickly reproducing the race 
condition, but I certainly wouldn't use it for measuring or optimizing 
performance as it wasn't designed for that - the ratio of add/remove loggers to 
callhandlers calls is likely to be unrepresentative of a real application, and 
there's vastly more contention on calling add/remove loggers than you'd see in 
the wild. 

Do you see any downsides to the immutable self.handlers approach, other than 
performance of add/remove logger being a little lower?

Personally I think we're on safer ground if we permit add/remove logger be 
slightly slower (but at least correct! correctness trumps performance), but 
only if we avoid regressing the more important performance of logging itself. 

Does that seem reasonable?

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Vinay Sajip]

Vinay Sajip  added the comment:

I'm not very keen on this approach, because it needs to be implemented across 
all shells and maintenance in this area can be a headache because not everyone 
has knowledge of multiple shells.

There already are hooks for customising behaviour - you can subclass EnvBuilder 
and override e.g. setup_scripts to update the venv with the exact scripts you 
want. This puts the maintenance cost onto the people who need this 
functionality (it doesn't seem like a very common use case).

--

___
Python tracker 

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

[issue37352] Typo in documentation: "to making it easy"

[Julien Palard]

New submission from Julien Palard :

In Doc/faq/design.rst there's "with an eye to making it easily tested.".

I'm not native english, but I think "making" is wrong here, maybe "make"?

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 346141
nosy: docs@python, mdk
priority: normal
severity: normal
status: open
title: Typo in documentation: "to making it easy"
type: enhancement

___
Python tracker 

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

[issue37347] Reference-counting problem in sqlite

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +berker.peksag

___
Python tracker 

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

[issue37353] Source code has not always been forward-compatible

[Julien Palard]

New submission from Julien Palard :

In Doc/library/parser.rst I can read:

The parse trees are not typically compatible from one version to another, 
whereas source code has always been forward-compatible.

But I don't think this is right, I think of print for example.

Maybe just remove ", whereas source code has always been forward-compatible" or 
rewrite it so say source is just more stable than parse trees?

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 346142
nosy: docs@python, mdk
priority: normal
severity: normal
status: open
title: Source code has not always been forward-compatible

___
Python tracker 

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

[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging

[Vinay Sajip]

Vinay Sajip  added the comment:

> I'd prefer correctness to be always there automatically, rather than 
> something the user must remember to enable by setting a flag such as 
> lockCallHandling

Yes, I agree, I was just looking at different approaches while mulling all this 
over. Correctness-by-default can of course always be implemented by setting 
lockCallHandling to True by default, which is what I have currently in my 
benchmark testing.

Re. your change:

- self.handlers.remove(hdlr)
+ newhandlers = list(self.handlers)
+ newhandlers.remove(hdlr)
+ self.handlers = hdlr

Did you mean self.handlers = newhandlers in that last line? That's what I 
assumed you meant, but you've posted that twice now, so I'm not sure what 
you're getting at.

I agree that having a slower add/removeHandler is acceptable - certainly better 
than slowing down Logger.handle(). But I'm not sure about

> so without relying on any GIL locking callHandlers will still see the old 
> list or the new list

on platforms other than CPython, since we can't be sure where thread 
pre-emption might happen (i.e. it could happen inside a source code line 
boundary) and locking at least has the benefit of having defined semantics.

The other issue is where someone might have subclassed and overridden 
add/removeHandler methods, for whatever reason. I know it's unlikely, but one 
never knows.

I think we're broadly on the same page. I'm just not yet sure what the best 
approach is :-)

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Caleb Donovick  added the comment:

Common python libraries that make use of environmental variables:
- django
- flask
- jupyter
- TensorFlow
This is just off the top my head.  While most developers are probably fine just 
setting the required variables at a system level that doesn't mean they should. 
 The whole point of virtual environments is to avoid global state.

Overriding setup scripts is hardly a trivial task.  One has to completely 
recreate the activate script to achieve the desired behavior.

--

___
Python tracker 

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

[issue37352] Typo in documentation: "to making it easy"

[Zachary Ware]

Zachary Ware  added the comment:

"making" looks fine to me as a native English speaker.  I'm not sure it's 
properly correct English, but it's fine colloquially and I don't think "make" 
would improve it :)

If anything, I'd change "to" to "toward", or possibly replace "an eye to" with 
"the goal of".

--
nosy: +zach.ware

___
Python tracker 

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

[issue37353] Source code has not always been forward-compatible

[Zachary Ware]

Zachary Ware  added the comment:

Perhaps just adding "within a major release series" after "forward-compatible" 
would be sufficient?

--
nosy: +zach.ware

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Caleb Donovick  added the comment:

In regards to the added complexity by needing to be implemented across all 
shells, the functionality I am requesting already exists across all shells 
(e.g. setting PYTHONPATH) just not in a extensible way.

--

___
Python tracker 

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

[issue37352] Typo in documentation: "to making it easy"

[YoSTEALTH]

YoSTEALTH  added the comment:

"Writing test suites is very helpful, and you might want to plan your code 
based on expectation of making it easy for testing."

--
nosy: +YoSTEALTH

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Vinay Sajip]

Vinay Sajip  added the comment:

> Common python libraries that make use of environmental variables

I didn't say environment variables weren't commonly used. I'm talking about the 
specific functionality this issue is about.

> Overriding setup scripts is hardly a trivial task. One has to completely 
> recreate the activate script to achieve the desired behavior.

Not trivial, but not overly onerous either, e.g. just point to your own scripts 
subtree in the overridden method. Isn't your proposal to submit a different 
activate script?

> the functionality I am requesting already exists across all shells

I'm talking about the code to set, reset your custom environment variables - 
where is that already existent across all shells?

I'm not saying what you want is unreasonable - it's just putting it into the 
stdlib this way that I'm not sure about.

--

___
Python tracker 

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

[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

> BUT I think removing the `if getattr(obj, '__code__', None)` from 
> `_is_async_obj` actually makes this work correctly. It is possible for a 
> coroutine object to not have a __code__, but I don't think it is possible for 
> a coroutine function to be missing a __code__. 

Sorry, I am little confused here. If the code attribute check is removed then 
my test case in PR fails since obj.__code__ that is passed through 
iscoroutinefunction returns True. Maybe something along the lines of below that 
if there is a __code__ attribute then always check it's of CodeType. So that my 
test passes with MagicMock.__code__ detected.

If I understand the awaitable examples correctly, mocking the obj which is an 
Awaitable should be returning an AsyncMock. But obj doesn't contain __code__ 
and hence check for inspect.isawaitable is never done causing 
_is_async_obj(obj) to return False and subsequently it's patched with MagicMock.


from collections.abc import Awaitable
from unittest.mock import patch

class NewCoroutine(Awaitable):
def __await__():
pass

obj = NewCoroutine()

with patch(f"{__name__}.obj") as m:
print(m)

$ ./python.exe ../backups/bpo37251_awaitable.py


On removing the __code__ attribute check my test case of MagicMock with 
__code__ passes through iscoroutinefunction. Perhaps an acceptable tradeoff 
would be to check for __code__ and if present to be a CodeType or else to 
resume normal check like below. This way an AsyncMock is returned. Also there 
is no test failure. I have less understanding on asyncio terminologies over 
coroutine and awaitables so feel free to correct me if I am wrong. I guess it 
would be also helpful to have good number of tests for different asyncio object 
cases so that this could also be documented.

$ ./python.exe ../backups/bpo37251_awaitable.py


# _is_async_obj to check for __code__ to be CodeType only if present.

def _is_async_obj(obj):
code = getattr(obj, '__code__', None)
if code and not isinstance(code, CodeType):
return False
return asyncio.iscoroutinefunction(obj) or inspect.isawaitable(obj)

# Also verified asyncio.sleep() to return True for _is_async_obj with above 
definition

>>> from unittest.mock import _is_async_func, _is_async_obj
>>> import asyncio
>>> _is_async_obj(asyncio.sleep(1))
:1: RuntimeWarning: coroutine 'sleep' was never awaited
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
True

--

___
Python tracker 

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

[issue37351] Drop libpython38.a from Windows release

[Steve Dower]

Steve Dower  added the comment:

Turns out that using distutils/setuptools with --compiler=mingw32 is just 
doomed to fail when it hits get_msvcr(), which has never been updated for 
Python 3.5 onwards.

So I think it's probably safe to assume that this scenario isn't a real thing 
and people are linking MinGW/Python in some other way?

--

___
Python tracker 

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

[issue19982] Add a "target" parameter to runpy.run_path and runpy.run_module

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue24214] UTF-8 incremental decoder doesn't support surrogatepass correctly

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This change seems to have caused test failure reported in 
https://github.com/python-hyper/wsproto/issues/126


from codecs import getincrementaldecoder
decoder = getincrementaldecoder("utf-8")()
print(decoder.decode(b'f\xf1\xf6rd', False))

# With this commit 7a465cb5ee

➜  cpython git:(7a465cb5ee) ./python.exe /tmp/foo.py
f

Before 7a465cb5ee

➜  cpython git:(38f4e468d4) ./python.exe /tmp/foo.py
Traceback (most recent call last):
  File "/tmp/foo.py", line 3, in 
print(decoder.decode(b'f\xf1\xf6rd', False))
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/codecs.py", 
line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf1 in position 1: invalid 
continuation byte

--
nosy: +xtreak

___
Python tracker 

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

[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed

[Brett Cannon]

New submission from Brett Cannon :

If Activate.ps1 was made to not have substitutions upon generation and be an 
entirely static file, then the file could be signed and thus not require people 
to lower their security requirements in PowerShell in order to activate their 
virtual environments.

--
components: Library (Lib)
messages: 346154
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Write PowerShell Activate.ps1 to be static so it can be signed
type: enhancement

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

If we're in doubt, we should just apply PR 14193. It's essentially a one-line 
patch that fixes actual problems experienced by users and which doesn't break 
anything. Why should we *not* apply it?

I know that we're not obliged to fix anything, but that is besides the point 
given that a fix exists.

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Brett Cannon]

Brett Cannon  added the comment:

I mentioned on python-ideas and opened https://bugs.python.org/issue37354 to 
actually make the Activate.ps1 file static for security purposes.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue37355] SSLSocket.read does a GIL round-trip for every 16KB TLS record

[Josh Snyder]

New submission from Josh Snyder :

Background:

SSLSocket.read drops the GIL and performs exactly one successful call to  
OpenSSL's `SSL_read`, whose documentation states "At most the contents of one 
record will be returned". TLS records are at most 16KB, so high throughput 
(especially multithreaded) TLS reception can become bottlenecked on the GIL.

Proposal:

For non-blocking sockets, call SSL_read in a loop until the user-supplied limit 
is reached or no bytes are available on the socket. I don't know of a way to 
safely improve performance for blocking sockets.

Initial testing:

I performed initial testing using 32 threads pinned to 16 cores, downloading 
and re-assembling a single 140270MB file from a "real world" TLS sender. This 
resulted in a 4x increase in throughput, a 6.6x reduction in voluntary context 
switches, a 3.5x reduction in system time. User time did increase by 43%, so 
the overall reduction in CPU usage was only 2.67x.

 before after
 wall clock time (s):29.637 7.116
 user time (s)  : 8.79312.584
 system time (s):   105.11830.010
 user + system time (s) :   113.91142.594
 cpu utilization (%):   384   599 
 voluntary switches : 1,653,065   248,484
 speed (MB/s)   :  4733 19712

My git branch (currently a draft) is at 
https://github.com/hashbrowncipher/cpython/commits/faster_tls

--
assignee: christian.heimes
components: SSL
messages: 346156
nosy: christian.heimes, josnyder
priority: normal
severity: normal
status: open
title: SSLSocket.read does a GIL round-trip for every 16KB TLS record
type: performance

___
Python tracker 

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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

What do you mean with re-raise? The issue is not closed. If you have some 
proposal to overcome the limitations, the best approach is to comment here in 
the issue.

--

___
Python tracker 

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

[issue37352] Typo in documentation: "to making it easy"

[Carol Willing]

Carol Willing  added the comment:

I agree with Zach's suggestions.

If I were to rewrite and pass through a grammar checker, I would get closer to 
this (removing the verbose "an eye to":

Writing test suites is very helpful, and you might want to design your code to 
make it easily tested.

In other words, it is fine as is or with modifications. :-)

--
nosy: +willingc

___
Python tracker 

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

[issue37353] Source code has not always been forward-compatible

[Carol Willing]

Carol Willing  added the comment:

"...though source code has usually been forward-compatible within a major 
release series."

Agree with your thoughts Julien and Zach. Perhaps remove "whereas" as well.

--
nosy: +willingc

___
Python tracker 

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

[issue37340] remove free_list for bound method objects

[Josh Rosenberg]

Change by Josh Rosenberg :


--
nosy: +josh.r

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Caleb Donovick  added the comment:

> I didn't say environment variables weren't commonly used. I'm talking about 
> the specific functionality this issue is about.

This is likely true, to most people venv is black magic.  That doesn't mean 
that people wouldn't use it if the functionality existed though.  In fact this 
the first example given by virtualenvwrapper 
https://virtualenvwrapper.readthedocs.io/en/latest/scripts.html#example-usage

I personally don't use virtualenvwrapper because you they use a centralized 
list of env's which is non-starter for me.  I maintain dozens of envs (one per 
project, sometimes one per branch). So one big list would be a nightmare.

> I'm talking about the code to set, reset your custom environment variables - 
> where is that already existent across all shells?

My point is that this code is not really different than the code to set 
PYTHONPATH.

> I'm not saying what you want is unreasonable - it's just putting it into the 
> stdlib this way that I'm not sure about.

Is there an architecture that would be less objectionable?

> I mentioned on python-ideas and opened https://bugs.python.org/issue37354 to 
> actually make the Activate.ps1 file static for security purposes.

I am curious how you plan to achieve this without reducing the functionality of 
venv?

--

___
Python tracker 

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

[issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +14099
pull_request: https://github.com/python/cpython/pull/14275

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Carol Willing]

Carol Willing  added the comment:

Petr, Thanks for the thoughtful summary.

If I am understanding the many messages in this and the other related issue and 
by looking at this with a scientific Python hat on (not as the Steering 
Council), I'm inclined to favor Nick's approach if possible:

> 1. In 3.8.0b2, move tp_print to the end of the structure (rather than 
> removing it entirely) to make the "type->tp_print" in the old Cython 
> generated code harmless rather than a compilation error
>2. In 3.9.0a1, remove it entirely again

I agree that we shouldn't punish our users. IMHO Cython should get the benefit 
of a compromise, though not a long term guarantee, related to tp_print since 
Cython addresses a very real need for performance in scientific code. 

While Cython may be able to respond within the beta period, scientific projects 
that depend on it may lag longer as rebuilds and releases will need to happen 
on PyPI, conda, and conda-forge. Release versioning is critical in the science 
world as we depend on it for scientific research reproducibility. While we may 
not come up with an ideal solution for everyone, let's try to find something 
acceptable for Cython and the Core Python devs/users.

--
nosy: +willingc

___
Python tracker 

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

[issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files

[Zackery Spytz]

Zackery Spytz  added the comment:

PR 14275 converts Modules/overlapped.c. Many methods now use METH_FASTCALL.

--
nosy: +ZackerySpytz

___
Python tracker 

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

[issue37351] Drop libpython38.a from Windows release

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +14100
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14276

___
Python tracker 

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

[issue37353] Source code has not always been forward-compatible

[Prateek Nayak]

Change by Prateek Nayak :


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

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Steve Dower]

Steve Dower  added the comment:

> While Cython may be able to respond within the beta period, scientific 
> projects that depend on it may lag longer as rebuilds and releases will need 
> to happen on PyPI, conda, and conda-forge. Release versioning is critical in 
> the science world as we depend on it for scientific research reproducibility. 
> While we may not come up with an ideal solution for everyone, let's try to 
> find something acceptable for Cython and the Core Python devs/users.

Cython has already responded and made a new release, so the problem would be 
whether the scientific projects will release new sdists some time in the next 
four months (they will almost all have to do new wheels for 3.8 too).

Is four months really an unreasonable timeline? I thought most of these 
packages released more frequently than CPython.

--

___
Python tracker 

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

[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed

[Caleb Donovick]

Change by Caleb Donovick :


--
nosy: +donovick

___
Python tracker 

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

[issue36511] Add Windows ARM32 buildbot

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +14102
pull_request: https://github.com/python/cpython/pull/14279

___
Python tracker 

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

[issue37289] regression in Cython when pickling objects

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 1e61504b8b941494f3ac03e0449ddbbba8960175 by Pablo Galindo in 
branch 'master':
bpo-37289: Add a test for if with ifexpr in the peephole optimiser to detect 
regressions (GH-14127)
https://github.com/python/cpython/commit/1e61504b8b941494f3ac03e0449ddbbba8960175


--

___
Python tracker 

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

[issue36511] Add Windows ARM32 buildbot

[Steve Dower]

Steve Dower  added the comment:


New changeset 43615485f1222cd9a94421a96cb7110bb52e1b8b by Steve Dower in branch 
'3.8':
bpo-36511: Improve ARM32 buildbot scripts (GH-14251)
https://github.com/python/cpython/commit/43615485f1222cd9a94421a96cb7110bb52e1b8b


--

___
Python tracker 

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

[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed

[Vinay Sajip]

Vinay Sajip  added the comment:

How would you plan to replace the functionality where the venv's bin path is 
substituted into the script? Purely through introspecting its own path?

I see that PowerShell is/will be portable to e.g. Linux environments, but I 
presume the security requirements you refer to are purely a Windows constraint 
- is that right?

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Brett Cannon]

Brett Cannon  added the comment:

> I am curious how you plan to achieve this without reducing the functionality 
> of venv?

PowerShell has a full programming language and all details can be found in 
pyvenv.cfg now as of Python 3.8. So Activate.ps1 can read that file to get what 
it needs to set paths and the prompt which is what gets substituted into the 
generate Activate.ps1.

--

___
Python tracker 

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

[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed

[Brett Cannon]

Brett Cannon  added the comment:

> How would you plan to replace the functionality where the venv's bin path is 
> substituted into the script? Purely through introspecting its own path?

It's stored in pyvenv.cfg.

> I presume the security requirements you refer to are purely a Windows 
> constraint - is that right?

Yes (at least for now; not sure what PowerShell Core plans to do about this 
sort of thing long-term).

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Vinay Sajip]

Vinay Sajip  added the comment:

> Is there an architecture that would be less objectionable?

One thing I would consider is the ability to configure a custom_script_path in 
the same way as other parameters are now. It would be used as follows: If not 
None, it should specify a directory, and the files in there would be copied to 
the target venv *after* the standard scripts are copied (possibly overwriting 
ones already there, such as "activate"), with the same variable substitutions 
that are currently done.

This approach allows for other things than just custom environment variable 
setting, and so it seems a more generic solution to the issue of 
customisability. While it involves the developers who require such 
functionality to maintain those scripts, it seems fair to place the onus on 
them, and not on stdlib maintainers.

--

___
Python tracker 

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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Caleb Donovick  added the comment:

>PowerShell has a full programming language and all details can be found in 
>pyvenv.cfg now as of Python 3.8. So Activate.ps1 can read that file to get 
>what it needs to set paths and the prompt which is what gets substituted into 
>the generate Activate.ps1.

Then that should be fairly orthogonal to this issue.  We should be able to 
store key, value pairs in the config and set the environmental variables 
accordingly.

--

___
Python tracker 

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

[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed

[Paul Moore]

Paul Moore  added the comment:

How will this interact with EnvBuilder.install_scripts() (which explicitly 
states that it performs textual substitution)?

Note that I'm not aware of anyone who actually uses the ability to subclass 
EnvBuilder, but I wouldn't be surprised to find that people do...

--

___
Python tracker 

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

[issue37356] Name of 64-bit OpenSSL v1.1.1 DLLs

[Phil Thompson]

New submission from Phil Thompson :

In the 3.8b1 64-bit Windows installer the names of the OpenSSL DLLs do not have 
the -x64 suffix which seems to be the convention (and is the default when 
building OpenSSL from source). The convention is followed in the 3.7.0 to 3.7.3 
installers. I haven't yet checked the 3.7.4rc1 installer.

--
assignee: christian.heimes
components: Installation, SSL, Windows
messages: 346172
nosy: christian.heimes, paul.moore, philthompson10, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: Name of 64-bit OpenSSL v1.1.1 DLLs
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue24214] UTF-8 incremental decoder doesn't support surrogatepass correctly

[STINNER Victor]

Change by STINNER Victor :


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

[issue37349] venv.EnvBuilder environmental variable hooks

[Caleb Donovick]

Caleb Donovick  added the comment:

I have another idea, instead of baking in the semantics of the environmental 
variables, we could simply add the hooks __VENV_ACTIVATE_EXTRAS__ and 
__VENV_DEACTIVATE_EXTRAS__ to activate. By default they would be replaced by 
'', but would allow subclasses to extend the behavior of activate / deactivate 
arbitrarily. 

> One thing I would consider is the ability to configure a custom_script_path 
> in the same way as other parameters are now. It would be used as follows: If 
> not None, it should specify a directory, and the files in there would be 
> copied to the target venv *after* the standard scripts are copied (possibly 
> overwriting ones already there, such as "activate"), with the same variable 
> substitutions that are currently done.

I'll take a stab at implementing this if the above proposal is not acceptable.

--

___
Python tracker 

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

[issue37356] Name of 64-bit OpenSSL v1.1.1 DLLs

[Steve Dower]

Steve Dower  added the comment:

Yes, I noticed that they changed with OpenSSL 1.1.1a, but as far as I can tell 
we didn't do anything to cause that - our build definition is still the same, 
and uses "perl Configure VC-WIN64A-masm && nmake".

Is this causing issues? Or is it just something that you noticed?

--

___
Python tracker 

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

[issue24772] Smaller viewport shifts the "expand left menu" character into the text

[karl]

karl  added the comment:

I'm at Mozilla All Hands this week. 
I'll check if my solution still makes sense next week and will make a pull 
request and/or propose another solution. 
Thanks for the reminder. adding to my calendar.

--

___
Python tracker 

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

[issue36511] Add Windows ARM32 buildbot

[Paul Monson]

Change by Paul Monson :


--
pull_requests: +14103
pull_request: https://github.com/python/cpython/pull/14280

___
Python tracker 

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

[issue37352] Typo in documentation: "to making it easy"

[YoSTEALTH]

YoSTEALTH  added the comment:

programmers "plan" their code, they don't "design" it, as far as i know!

--

___
Python tracker 

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

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Carol Willing]

Carol Willing  added the comment:

> Is four months really an unreasonable timeline? I thought most of these 
> packages released more frequently than CPython.

I can't really predict with any accuracy what the release cycle is for most 
scientific projects. Anywhere from 1 month to 9 months probably covers 90% of 
the actively maintained scientific projects. So is four months unreasonable? 
Not entirely unreasonable IMHO. Six months seems a safer estimate. What makes 
it difficult to predict is that many of the scientific projects do not have 
rigid release cycles and push out releases when a specific feature or bug fix 
warrants it.

Perhaps it would be helpful for someone to recap the current options on the 
table for moving forward and the most significant risk to Cython, Projects 
using Cython, or CPython by selecting each option.

Thanks.

--

___
Python tracker 

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