Hi,
First of all, I just found an old issue that we will solved by my PEP 587 :-)
Add Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors
https://bugs.python.org/issue30560
I studied code of applications embedding Python. Most of them has to
decode bytes strings to get
On Fri, 10 May 2019 at 18:54, Ned Deily wrote:
>
> Eek! I was just doing a bit of branch cleanup in the cpython repo and
> managed to trigger a bunch (30-ish) of duplicate checkin messages to
> bugs.python.org for old commits. I will remove them from b.p.o. Please
> ignore any 3.4 spam
ACTIVITY SUMMARY (2019-05-03 - 2019-05-10)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7084 ( +3)
closed 41542 (+88)
total 48626 (+91)
Open issues
Eek! I was just doing a bit of branch cleanup in the cpython repo and managed
to trigger a bunch (30-ish) of duplicate checkin messages to bugs.python.org
for old commits. I will remove them from b.p.o. Please ignore any 3.4 spam
email. Sorry!
--
Ned Deily
n...@python.org -- []
On 2019-05-10 00:07, Petr Viktorin wrote:
METH_FASTCALL is currently not documented, and it should be renamed
before it's documented. Names with "fast" or "new" generally don't age
well.
Just to make sure that we're understanding correctly, is your proposal
to do the following:
- remove the
Petr Viktorin schrieb am 10.05.19 um 00:07:
> On 5/9/19 5:33 PM, Jeroen Demeyer wrote:
>> Maybe you misunderstood my proposal. I want to allow both for extra
>> flexibility:
>>
>> - METH_FASTCALL (possibly combined with METH_KEYWORDS) continues to work
>> as before. If you don't want to care about
On 10.05.2019 02:58, Paul Ganssle wrote:
> This is only "only" for dateutil in the sense that no one other than
> dateutil implements tzinfo with the interface provided. If dateutil were
> /not/ already implemented with a list of offsets and their indexes, I
> would still propose this, and just
