[issue31314] email throws exception with oversized header input

Dong-hee Na added the comment: I sent a patch if anyone have a time, please take a look :) -- nosy: +corona10 ___ Python tracker ___ ___

[issue31742] Default to emitting FutureWarning for provisional APIs

New submission from Nick Coghlan : Chatting to Donald Stufft and Amber Brown about the way we currently handle provisional APIs, I think they have a legitimate concern that we may not be gathering adequately informed consent from users when they depend on APIs that we've reserved the right to

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: Another advantage of this approach: anyone running their tests in a "no warnings allowed" configuration would get a hard failure when dependencies on a provisional API were unexpectedly introduced (e.g. when updating a third party library), rather than silently

[issue31742] Default to emitting FutureWarning for provisional APIs

Nick Coghlan added the comment: This is also fairly similar to Rust's approach of using feature flags to explicitly opt-in to unstable features: https://doc.rust-lang.org/unstable-book/ -- ___ Python tracker ___

[issue31742] Default to emitting FutureWarning for provisional APIs

Guido van Rossum added the comment: While I understand the sentiment, having this warning pop up every time you import a provisional module while developing code feels like harassment of the very users we'd like to try out the provisional APIs. It's also too course-grained -- most of the time

[issue31742] Default to emitting FutureWarning for provisional APIs

Donald Stufft added the comment: The fundamental problem is that unless you're closely following the development of python-dev, it's really really easy to use a provisional module without knowing that you are. Take asyncio for example, as far as I can tell the documentation that noted it was

[issue31742] Default to emitting FutureWarning for provisional APIs

Amber Brown added the comment: Donald hits it on the head for me. As long as the code is not covered by the same API deprecation contract that the rest of the standard library is, it should make it obvious when attempting to use it. I can be relatively certain that a lot of people were not aw

[issue31736] PEP 485 tiny typo

Berker Peksag added the comment: Thank you for the report. Fixed in https://github.com/python/peps/commit/070dc7e037e5f66e4e17b661641503815a8bbe05 (By the way, you can report issues like this at https://github.com/python/peps/issues or send a PR directly.) -- nosy: +berker.peksag res

[issue31728] crashes in _elementtree due to unsafe decrefs of Element.text and Element.tail

Oren Milman added the comment: As serhiy pointed out in a comment in PR 3924, setting self->text or self->tail to NULL might lead to an assertion failure, so we should also prevent the following assertion failure (and the similar one for tail): import xml.etree.ElementTree class X: def __de

[issue31584] Documentation Language mixed up

INADA Naoki added the comment: Japanese HTML has this line: https://docs.python.org/2/faq/design.html"; /> I suspect this line affects CDN's cache. But I can't find document about canonical link in fastly's document. -- nosy: +inada.naoki ___ P

[issue31584] Documentation Language mixed up

INADA Naoki added the comment: https://twitter.com/miyagawa/status/917629042278359040 Miyagawa-san, the member of Fastly told me they doesn't use HTML content for cache key, unless we customize VCL. But I can't find VCL for docs.python.org in github.com/python. -- ___

[issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters?

Julien Palard added the comment: Today I tried without utf8x and an up-to-date version of texlive, errors looked less mystical, so I was able to open a readable / easy to reproduce issue: https://github.com/sphinx-doc/sphinx/issues/4136 I then followed the idea of trying xetex and I was able

[issue31589] Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters?

Change by Roundup Robot : -- keywords: +patch pull_requests: +3913 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-lis

[issue27172] Undeprecate inspect.getfullargspec()

Nick Coghlan added the comment: Larry, your personal insult is entirely unwelcome, unnecessary, and unappreciated, especially as it's wrong regarding the Python 2/3 compatibility concerns. While getfullargspec() is indeed new in Python 3.x, it's also deliberately designed as a *drop-in repla

[issue27172] Undeprecate inspect.getfullargspec()

Nick Coghlan added the comment: Note: the minor incompatibility that required getfullargspec() to be a separate API in the first place is the fact that it returns a 7 element named tuple instead of a 4 element one. This means that hybrid 2/3 code needs to consistently use name based item acc

<    1   2