[issue36952] fileinput input's and Fileinput's bufsize=0 marked for removal in 3.8

New submission from Matthias Bussonnier : Can likely thus be removed now. See also https://bugs.python.org/issue33563 that was tracking better deprecation warnings. If not removed documentation should bump removal to 3.9 -- components: Library (Lib) messages: 342769 nosy: mbussonn

[issue36933] sys.set_coroutine_wrapper documented as to be removed in 3.8 (still there)

New submission from Matthias Bussonnier : See issue32591 It was deprecated in 3.7, so maybe removed only in 3.9? -- components: Interpreter Core messages: 342615 nosy: mbussonn priority: normal severity: normal status: open title: sys.set_coroutine_wrapper documented as to be removed

[issue36932] asyncio-task.rst could use proper deprecated-removed directive

Change by Matthias Bussonnier : -- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issu

[issue36932] asyncio-task.rst could use proper deprecated-removed directive

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13260 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36932> ___ _

[issue36932] asyncio-task.rst could use proper deprecated-removed directive

New submission from Matthias Bussonnier : SOme place in the documentation do not use the Deprected-remove directive (which is nice as it has a consistent pharing and is easy to search for), and deprecation warnings do not always have the version since deprecation which could be improved

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > I'll be working on CPython on Friday. Will take a look at your PR first thing. Thanks, let me know if the is anything I can do for you in exchange; also thanks again for sitting with me and stepping me through the things at Py

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: I see the 3.8 feature freeze seem to be end of next-week; do you think that async-exec (gh-13148) has a chance of getting in ? I'm happy to do modification to the PR but would need some more reviews. I'm happy to take some other tasks of your plate

[issue36917] ast.NodeVisitor no longer calls visit_Str

Matthias Bussonnier added the comment: > so my vote is to revert, keep the complexity in the compiler and out of user > code Playing Devil advocate here, but the complexity depends on what transformations user want to do; with the current state of 3.8, a user that wants to vis

[issue36917] ast.NodeVisitor no longer calls visit_Str

Matthias Bussonnier added the comment: > There would still be a breakage for that if someone was defining py36+ > `visit_Constant` (which would clobber the `ast.NodeVisitor.visit_Constant` if > we were to add it) Ok, it would still break in some cases, but that would still

[issue36917] ast.NodeVisitor no longer calls visit_Str

Matthias Bussonnier added the comment: Would it be useful to add a default implementation of `visit_Constant(self, node)` on NodeVisitor that go through all the isinstance() check and call the appropriate backward compatible method ? We would still have the simplification without having

[issue36917] ast.NodeVisitor no longer calls visit_Str

Change by Matthias Bussonnier : -- nosy: +mbussonn ___ Python tracker <https://bugs.python.org/issue36917> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32892] Remove specific constant AST types in favor of ast.Constant

Change by Matthias Bussonnier : -- nosy: +mbussonn ___ Python tracker <https://bugs.python.org/issue32892> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36912] Can't left-align strings using f-strings or format()

Matthias Bussonnier added the comment: > I thought I was missing something. Some sleep, probably. -- ___ Python tracker <https://bugs.python.org/issu

[issue36912] Can't left-align strings using f-strings or format()

Matthias Bussonnier added the comment: Aren't > and < the characters to right/left-align ? >>> foo = 'abc' >>> f"{foo:>10}" ' abc' >>> format(foo, '>10') ' abc' -- nosy: +mbussonn ___ Py

[issue36911] ast.parse outputs ast.Strs which do not differentiate between the ASCII codepoint 12 (literal new line) and the ASCII codepoints 134 and 156 ("\n")

Matthias Bussonnier added the comment: I believe this one is even before the ast, in the tokenizer. Though the AST is also doing some normalisation in identifiers (“ε” U+03B5 Greek Small Letter Epsilon Unicode Character , and “ϵ” U+03F5 Greek Lunate Epsilon Symbol Unicode Character get

[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals

Change by Matthias Bussonnier : -- nosy: +mbussonn ___ Python tracker <https://bugs.python.org/issue36906> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13286] PEP 3151 breaks backward compatibility: it should be documented

Change by Matthias Bussonnier : -- pull_requests: +13197 ___ Python tracker <https://bugs.python.org/issue13286> ___ ___ Python-bugs-list mailing list Unsub

[issue36895] time.clock() marked for removal in 3.8 – still there.

Matthias Bussonnier added the comment: Done: - 1 PR against master to remove the documentation and update api-and-feature-removals - and one against 3.7 to add the deprecated-removed. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36895] time.clock() marked for removal in 3.8 – still there.

Change by Matthias Bussonnier : -- pull_requests: +13195 ___ Python tracker <https://bugs.python.org/issue36895> ___ ___ Python-bugs-list mailing list Unsub

[issue13286] PEP 3151 breaks backward compatibility: it should be documented

Change by Matthias Bussonnier : -- pull_requests: +13194 ___ Python tracker <https://bugs.python.org/issue13286> ___ ___ Python-bugs-list mailing list Unsub

[issue36895] time.clock() marked for removal in 3.8 – still there.

Change by Matthias Bussonnier : -- pull_requests: +13193 stage: commit review -> patch review ___ Python tracker <https://bugs.python.org/issue36895> ___ _

[issue36895] time.clock() marked for removal in 3.8 – still there.

Matthias Bussonnier added the comment: > If we find a _good_ reason to delay this removal a cycle during the 3.8 betas > we can bring it back. > thanks for staying on top of the removal plan! Thanks to you for the quick integration; I'm happy if we need to bring it back, but at lea

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13177 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36896> ___ _

[issue36886] Failed to construct CodeType on Python-3.8.0a4

Matthias Bussonnier added the comment: Thanks for the update to the what's new Pablo. > let's open a new issue for the notice in types.rst to keep the discussion > isolated. See bpo-36896 -- ___ Python tracker <https://bugs.p

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

New submission from Matthias Bussonnier : >From bpo-36886, IT is unclear the FunctionTypes, CodeTypes ... etc are not stable between python versions, and the recent addition of `:=` change some of the signatures. This suggest 2 things: - A CYA sentence in types.rst "The

[issue36895] time.clock() marked for removal in 3.8 – still there.

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13176 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36895> ___ _

[issue36895] time.clock() marked for removal in 3.8 – still there.

Matthias Bussonnier added the comment: Vstiner, added you as you added the deprecation notice. I'm happy to take care of the removal and/or update the deprecation warning to 3.9. -- nosy: +vstinner ___ Python tracker <https://bugs.python.

[issue36895] time.clock() marked for removal in 3.8 – still there.

New submission from Matthias Bussonnier : Deprecation message in `timemodule.c` says: > "time.clock has been deprecated in Python 3.3 and will be removed from Python > 3.8: use time.perf_counter or time.process_time instead" Should be bumped to 3.9 – or time.clock s

[issue36886] Failed to construct CodeType on Python-3.8.0a4

Matthias Bussonnier added the comment: > There are other projects that have already added a fix for the new parameter > positionally. If we add it to be the last (that still will break the old > call) we would break them again. Understandable > The documentation neve

[issue36886] problem with Types on Python-3.8.0a4

Matthias Bussonnier added the comment: If types is not supposed to be stable, could a warning be added at top of https://docs.python.org/3/library/types.html that it should not be considered stable, and/or to CodeType docs to indicate the signature has changed in 3.8 ? If it is supposed

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: Thank Yuri for the guidance; I worked on it, cleaned things up a bit and posted a draft PR (#13148) with some example. That helps cleaning up a lot of code; and in the PR is a ~30 line example that implement an asyncio-repl

[issue34616] implement "Async exec"

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13063 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34616> ___ _

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Did I miss something? No I think for the async stuff that should be a big improvement already. Either a flag, or different "MODE", like 'single','exec' and 'eval'. I'l love for something like 'exec' but where not only we can have multip

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: Extra notes from in-person discussion; We might want a both a Sync-REPL and Async-REPL `compile()` mode depending on wether the REPL support async. One of the other question was wether `exec` should look at wether an eventloop is running

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > async-input isn't even useful for ipython, is it? you use prompt-toolkit :-) You don't have to use prompt_toolkit (https://github.com/ipython/rlipython), but yes we don't need this. > Do you have a patch for this? If not I can take

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: Slides and demo (videos) during PyCon2019 Language Summit: https://github.com/Carreau/talks/tree/master/2019-05-01-Language-Summit One question was how to handle non-asyncio in Core Python, REPL. My response was to not take care of that in the first

[issue22412] Towards an asyncio-enabled command line

Matthias Bussonnier added the comment: I believe https://bugs.python.org/issue34616 is related as it track async-exec and seem to have a couple of devs that are favorable to it. -- nosy: +mbussonn ___ Python tracker <https://bugs.python.

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > Or actually there are two options to think about: you can submit a general > talk, or submit a talk to the language summit. (Or write two talks and do > both, I guess.) They're pretty different – the summit is a more informal > thi

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: In IPython we use `prompt_toolkit` which does already provide a async readline alternative. Also have a look at https://github.com/ipython/ipython/blob/320d21bf56804541b27deb488871e488eb96929f/IPython/core/interactiveshell.py#L121-L150 Seem

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: So through time our heuristic to check wether a code should be async or not grew: https://github.com/ipython/ipython/blob/320d21bf56804541b27deb488871e488eb96929f/IPython/core/async_helpers.py#L94-L165 There also seem to be some code that uses

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > A utility to check whether an AST requires async mode should be fairly > straightforward. Here is one case we forgot in IPython apparently : In [1]: x = 1 ...: def f(): ...: nonlocal x ...: x = 1 This is not detected as a

[issue34616] implement "Async exec"

Matthias Bussonnier added the comment: > I think the first thing is to add async "modes" to compile: in particular > "async-exec" and "async-single". These would be like the current "exec" and > "single" modes respectively, except

[issue34616] implement "Async exec"

Change by Matthias Bussonnier : -- nosy: +minrk, willingc, yselivanov ___ Python tracker <https://bugs.python.org/issue34616> ___ ___ Python-bugs-list mailin

[issue34616] implement "Async exec"

New submission from Matthias Bussonnier : Hi, This is an issue, prompted by twitter (https://twitter.com/Mbussonn/status/1038866329971961859) and by the imminent release of IPython 7.0 that provides an async REPL to discuss the introducion of something I'll call "Async exec",

[issue33910] update random.Random 's parameter to have a proper name.

Matthias Bussonnier added the comment: Thanks @rhettinger, this is a perfectly valid position, and one of the respons I was expecting. > That said, it doesn't seem to have ever caused a problem in practice (this > API has been around for a very long time) I have myself not found

[issue33910] update random.Random 's parameter to have a proper name.

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +7427 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33910> ___ _

[issue33910] update random.Random 's parameter to have a proper name.

New submission from Matthias Bussonnier : Docs of random.Random always refer to it with Random([seed]) (`lib/random.py`), tough the parameter is actually named `x` making it : - non obvious what it does. - hard to search for. - hard to remember when using kwargs. Obviously changing

[issue33783] Use proper class markup for random.Random docs

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +7425 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue33468] Add try-finally contextlib.contextmanager example

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +7424 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue33477] Document that compile(code, 'exec') has different behavior in 3.7+

Matthias Bussonnier added the comment: Closing as the ast changes have been reverted. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue32911] Doc strings no longer stored in body of AST

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: > Just to quickly touch on Matthias' question about opt-in or deprecations, a > key thing to note is the ast module is automatically generated from the ASDL > file, so either of those approaches would req

[issue32911] Doc strings no longer stored in body of AST

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: Łukasz Langa wrote: > Inadasan, I think what we should do is to amend `ast.parse()` and `compile()` > docs that mode="exec" treats given code as a module, we should even give the > docstri

[issue33604] HMAC default to MD5 marked as to be removed in 3.6

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: I've sent two PRs, one that updates the deprecation from PendingDeprecationWarning to DeprecationWarning that likely should get applied to 3.6, and 3.7 ? And a PR to actually remove the default

[issue33604] HMAC default to MD5 marked as to be removed in 3.6

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +6693 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33604] HMAC default to MD5 marked as to be removed in 3.6

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6692 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33604] HMAC default to MD5 marked as to be removed in 3.6

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: HMAC docs says digestmod=md5 default will be removed in 3.6, but was not. We should likely bumpt that to 3.8 in the documentation, and actually remove it in 3.8 -- messages: 317322 nosy: mbussonn priority:

[issue33594] add deprecation since 3.5 for a few methods of inspect.

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6680 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33594] add deprecation since 3.5 for a few methods of inspect.

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: inspect's getargspec, as well as Signature's from_function, and from_builtin are deprecated. They all emits DeprecationWarning but: The deprecation warning does not say since which version since are depr

[issue33582] formatargspec deprecated but does nto emit DeprecationWarning.

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6646 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33582] formatargspec deprecated but does nto emit DeprecationWarning.

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: Documentation says formatargspec is deprecated since 3.5, but no DeprecationWarnings are emitted, the docstring also does not mention this fact. -- assignee: docs@python components: Documentation messages:

[issue1792] o(n*n) marshal.dumps performance for largish objects with patch

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +6645 ___ Python tracker <rep...@bugs.python.org> <https://bugs.pytho

[issue17972] inspect module docs omits many functions

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6644 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue17972] inspect module docs omits many functions

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: Just came across the same issue. It think that the exact behavior may depend on functions. IT is also unclear when to use what sometime. For example, `getsource` seem to be preferable to findsource, getsource

[issue33477] Document that compile(code, 'exec') has different behavior in 3.7+

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6628 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33477] Document that compile(code, 'exec') has different behavior in 3.7+

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: Fair enough that what's new include things about Module > The first statement in their body is not considered as a docstring anymore. Note that this sentence read backward to me. I understand what is meant becaus

[issue33563] fileinput input's and Fileinput's bufsize=0 do not remit deprecationWarnings

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: In Lib/fileinput.py, passing bufsize=0 does not raise any DeprecationWarning. Also when using `input` the stacklevel could be better as it passes bufsize directly for FileInput. in Lib/test/test_filein

[issue33563] fileinput input's and Fileinput's bufsize=0 do not remit deprecationWarnings

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6618 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue12486] tokenize module should have a unicode API

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: > Why not just bless the existing generate_tokens() function as a public API, Yes please, or just make the private `_tokenize` public under another name. The `tokenize.tokenize` method try to magically detect encod

[issue33549] xmlbuilder's `_AsyncDeprecatedProperty` make no sens now that async is a keyword.

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6594 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33549] xmlbuilder's `_AsyncDeprecatedProperty` make no sens now that async is a keyword.

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: `Lib/xml/dom/xmlbuilder's DocumentLS try to catch the use of `obj.asyc` and warn that it's now `obj.async_`. Though now that async is a proper keyword `obj.async` is anyway SyntaxError, so the warning will likely

[issue33487] BZ2File(buffering=None) does not emit deprecation warning, deprecation version not documented.

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: > Actually it is ignored since 3.0. My bad, I have likely misread the history. PR updated. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33487] BZ2File(buffering=None) does not emit deprecation warning, deprecation version not documented.

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6472 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33487] BZ2File(buffering=None) does not emit deprecation warning, deprecation version not documented.

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: BZ2File(buffering=None) should emit a deprecation warning as the argument is deprecated. The deprecation message and documentation should say since when it is deprecated. (AFAICT since 3.3) -- messages:

[issue33461] json.loads(encoding=) does not emit deprecation warning.

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: I've opened https://github.com/python/cpython/pull/6784 as an alternative that removes it. I was worried to remove it so close to 3.7. -- ___ Python tracke

[issue33461] json.loads(encoding=) does not emit deprecation warning.

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +6471 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33477] Document that compile(code, 'exec') has different behavior in 3.7+

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: In recent Python the following >>> from ast import PyCF_ONLY_AST >>> compile("'a'", 'whatever', 'exec', PyCF_ONLY_AST).body In 3.6 it return [<_ast.Expr at 0x10b7441d0>]

[issue29204] Add code deprecations in ElementTree

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +6450 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33461] json.loads(encoding=) does not emit deprecation warning.

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6449 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33461] json.loads(encoding=) does not emit deprecation warning.

New submission from Matthias Bussonnier <bussonniermatth...@gmail.com>: The `encoding` keyword of json.loads is ignored and deprecated. AFAICT this is since Python 3.1. Passing a value for encoding does not emit a deprecation warning. -- messages: 316384 nosy: mbussonn pr

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +6387 ___ Python tracker <rep...@bugs.python.org> <https://bugs.pytho

[issue28167] remove platform.linux_distribution()

Change by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- keywords: +patch pull_requests: +6363 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue28167] remove platform.linux_distribution()

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: In the docs it is marked as "going to be removed in 3.7", and emitting PendingDeprecationWarning. I supposed it should either be updated to change to 3.8 and switch PendingDeprecationWarning to De

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: Let me try to explain better, I'm pretty sure there is just a misunderstanding from some of use in the vocabulary or presupposition we start from. I have the impression that you feel like the API will automaticall

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

Matthias Bussonnier <bussonniermatth...@gmail.com> added the comment: Your last description is about exactly what https://github.com/python-trio/trio/pull/176 is about (which I need to resurect) There are some issue with weakref some that I don't remember, but one of them is (IIRC)

[issue29593] Improve UnboundLocalError message for deleted names

Matthias Bussonnier added the comment: Thanks you all for your input, it seem like to much of electronic ink and time has been spend on this issue. For the sake of everyone and avoiding more to be spent, I'm going to close it. -- resolution: -> duplicate stage: -> resolved

[issue30772] Normalise non-ASCII variable names in __all__

Matthias Bussonnier added the comment: > I think that the names in __all__ should have the same NFKC normalisation > applied as the identifiers. Does it make sens to add to this issue : Ensure that all elements of __all__ are str ? (At least emit a warning ?) I have encounter a small

[issue13821] misleading return from isidentifier

Matthias Bussonnier added the comment: I have been bitten by that as well. I think the doc should mention to verify that the given string is normalized, not that it **should** be normalized. Agreed that If isidentifier could also possibly grow a `allow_non_nfkc=True` default parameter

[issue29660] Document that print/format_exception ignore etype

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +1994 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29660] Document that print/format_exception ignore etype

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +1993 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29660] Document that print/format_exception ignore etype

Matthias Bussonnier added the comment: Thanks @Mariatta, I'll try to cherry-pick! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- nosy: +mbussonn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29731] Ability to filter warnings to print current stack

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +406 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue29731] Ability to filter warnings to print current stack

New submission from Matthias Bussonnier: The warning module is extremely useful, especially the ability to change various level of verbosity and filter by multiple criteria. It is though sometime hard to pinpoint why a warning was triggered, or actually what triggered a warning

[issue29693] DeprecationWarning/SyntaxError in test_import

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- nosy: +mbussonn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue26389] Expand traceback module API to accept just an exception as an argument

Matthias Bussonnier added the comment: > (Optional) Change 'value' to 'exc' in the API to reflect the 3.x restriction > Keep the synonym until after 2.7. Do you mean after 2.7 EOL, or after 3.7 ? > etype: In 3.5+ document that it is an ignored dummy argument and that one can >

[issue26389] Expand traceback module API to accept just an exception as an argument

Matthias Bussonnier added the comment: > Another point is that it may be better to keep the existing parameter name > “value”, rather than (eventually?) replacing it with “exc”. I think both of > these things could be accomplished by juggling the “value” and “etype” > parameter

[issue29660] Document that print/format_exception ignore etype

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +297 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue26389] Expand traceback module API to accept just an exception as an argument

Matthias Bussonnier added the comment: I've attempted a Pull-request trying to implement what Brett is describing. See https://github.com/python/cpython/pull/327, and opened http://bugs.python.org/issue29660 to document that etype is ignored and decide wether it should emit DeprecationWarning

[issue29660] Document that print/format_exception ignore etype

New submission from Matthias Bussonnier: As far as I can tell, http://bugs.python.org/issue17911 made a couple of function in traceback ignore their first arguments (etype) and infer the type from the second one (evalue). (In git 6bc2c1e7 and 2f0441f0 respectively). At least print_exception

[issue26389] Expand traceback module API to accept just an exception as an argument

Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>: -- pull_requests: +287 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

<    1   2   3   >