On Thu., May 16, 2019, 15:56 Steve Dower, wrote:
> On 16May2019 1548, Pablo Galindo Salgado wrote:
> > > Will the folks using forks be happy to switch to the stdlib version?
> >>For example I can imagine that if black wants to process 3.7 input
> >>code while running on 3.6, it might prefer a
On Thu, May 16, 2019 at 1:23 PM Victor Stinner wrote:
>
> Le jeu. 16 mai 2019 à 20:58, Petr Viktorin a écrit :
> > I always thought the classic (exc_type, exc_value, exc_tb) triple is a
> > holdover from older Python versions, and all the information is now in
> > the exception instance.
> > Is
Le ven. 17 mai 2019 à 03:10, Gregory P. Smith a écrit :
> I like the feature, we should have it. It'll be useful for debugging and
> probably more.
>
> Which brings me to the annoying paint color question: These exceptions were
> most definitely raised. Thus the term "unraisable" is wrong. I
I like the feature, we should have it. It'll be useful for debugging and
probably more.
Which brings me to the annoying paint color question: These exceptions were
most definitely raised. Thus the term "unraisable" is wrong. I believe you
really mean "uncatchable".
-gps
On Thu, May 16, 2019 at
On 16May2019 1548, Pablo Galindo Salgado wrote:
> Will the folks using forks be happy to switch to the stdlib version?
For example I can imagine that if black wants to process 3.7 input
code while running on 3.6, it might prefer a parser on PyPI even if
he stdlib version were public, since the
On 16May2019 1441, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 23:17, Steve Dower a écrit :
You go on to say "pass an error message" and "keep repr(obj) if you
want", but how is this different from creating an exception that
contains the custom message, the repr of the object, and chains the
> Will the folks using forks be happy to switch to the stdlib version?
>For example I can imagine that if black wants to process 3.7 input
>code while running on 3.6, it might prefer a parser on PyPI even if
>he stdlib version were public, since the PyPI version can be updated
>independently of
On Thu, May 16, 2019 at 2:13 PM Pablo Galindo Salgado
wrote:
> I propose to remove finally the parser module as it has been "deprecated" for
> a long time, is almost clear that nobody uses it and has very limited
> usability and replace it (maybe with a different name)
> with pgen2 (maybe with
Le jeu. 16 mai 2019 à 23:15, Pablo Galindo Salgado
a écrit :
> The parser module has been "deprecated" (technically we recommend to prefer
> the ast module instead) since Python2.5 but is still in the standard library.
Importing it doesn't emit a DeprecationgWarning. It's only deprecated
in the
Le jeu. 16 mai 2019 à 23:46, Nathaniel Smith a écrit :
> A clever hook might want the actual object, so it can pretty-print it,
> or open an interactive debugger and let it you examine it, or
> something. Morally this is similar to calling repr(obj), but it
> doesn't literally call repr(obj).
On Thu, May 16, 2019 at 2:17 PM Steve Dower wrote:
> You go on to say "pass an error message" and "keep repr(obj) if you
> want", but how is this different from creating an exception that
> contains the custom message, the repr of the object, and chains the
> exception that triggered it?
A
Le jeu. 16 mai 2019 à 23:17, Steve Dower a écrit :
> You go on to say "pass an error message" and "keep repr(obj) if you
> want", but how is this different from creating an exception that
> contains the custom message, the repr of the object, and chains the
> exception that triggered it?
Well,
On 16May2019 1404, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 17:56, Steve Dower a écrit :
I really like this API, and I agree with Victor that we don't really
need more than the exception info. For future expansion, we can pass in
a different exception, no?
Sorry, I don't understand. I
Hi everyone,
TLDR
=
I propose to remove the current parser module and expose pgen2 as a
standard library module.
Some context
===
The parser module has been "deprecated" (technically we recommend to prefer
the ast module instead) since Python2.5 but is still in the standard
Le jeu. 16 mai 2019 à 17:56, Steve Dower a écrit :
> I really like this API, and I agree with Victor that we don't really
> need more than the exception info. For future expansion, we can pass in
> a different exception, no?
Sorry, I don't understand. I explained that we need more than
Le jeu. 16 mai 2019 à 20:58, Petr Viktorin a écrit :
> I always thought the classic (exc_type, exc_value, exc_tb) triple is a
> holdover from older Python versions, and all the information is now in
> the exception instance.
> Is the triple ever different from (type(exc), exc, exc.__traceback__)?
Hello,
I need a review on the PEP 574 implementation:
https://github.com/python/cpython/pull/7076
I would really like it to be in 3.8 and so ideally it should be merged
within two weeks.
Regards
Antoine.
___
Python-Dev mailing list
On Thu, May 16, 2019, 09:07 Steve Dower wrote:
>
> Actually, if the default implementation prints the exception message,
> how is this different from sys.excepthook? Specifically, from the point
> of customizing the hooks.
>
sys.excepthook means the program has fully unwound and is about to
On 5/16/19 3:23 AM, Victor Stinner wrote:
[...]
I modified my API to create an object to pack arguments. The new API
becomes sys.unraisablehook(unraisable) where unraisable has 4 fields:
exc_type, exc_value, exc_tb, obj.
[...]
I always thought the classic (exc_type, exc_value, exc_tb) triple is
> While I’m fine with the API you propose, you could consider keyword-only
arguments to help future proof the call signature. I don’t like it as much
because it’s not as backward compatibility proof, but it’s an option to
perhaps consider.
Let's say that we have: hook(*, exc_type, exc_value,
On May 16, 2019, at 03:12, Victor Stinner wrote:
> I came to the UnraisableHookArgs structseq idea because of my bad
> experience with extension warnings "hooks". Let me tell you this story
> :-)
Thanks for that!
> def showwarning(message, category, filename, lineno, file=None, line=None):
>
Hi All,
I have implemented PR fixing bpo-9584 few months ago. Recently, I was
encouraged that conversation on DEV mailing list should be started here on
DEV mailing list. From the conversation in bug report, I understood that
the main problem is that straightforward implementation can break a
Le jeu. 16 mai 2019 à 16:10, Thomas Wouters a écrit :
>> Would you be ok with a "PyConfig_Init(PyConfig *config);" function
>> which would initialize all fields to theire default values? Maybe
>> PyConfig_INIT should be renamed to PyConfig_STATIC_INIT.
>>
>> You can find a similar API for pthread
On 16May2019 0902, Steve Dower wrote:
Actually, if the default implementation prints the exception message,
how is this different from sys.excepthook? Specifically, from the point
of customizing the hooks.
If I were going to replace unraisablehook to do something on specific
exceptions, I'm
On 16May2019 0856, Steve Dower wrote:
On 16May2019 0647, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a
écrit :
For unraisable hook, it's not hard to imagine other useful parameters
that can be passed to the hook to provide more context about the
exception. For example,
On 16May2019 0647, Victor Stinner wrote:
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a écrit :
For unraisable hook, it's not hard to imagine other useful parameters
that can be passed to the hook to provide more context about the
exception. For example, right now we only pass one object. But
On 16May2019 0710, Thomas Wouters wrote:
A couple of things are documented as performing pre-initialisation
(PyConfig_SetBytesString, PyConfig_SetBytesArgv). I understand why, but
I feel like that might be confusing and error-prone. Would it not be
better to have them fail if
On 15May2019 1610, Victor Stinner wrote:
Thanks to the constructive discussions, I enhanced my PEP 587. I don't
plan any further change, the PEP is now ready to review (and maybe
even for pronouncement, hi Thomas! :-)).
My view is that while this is a fantastic PEP and the groundwork that
Thanks for adding your input, Gregory! It's much appreciated.
I'll shuffle your comments around a bit, as I'd rather address the
themes than each individual point.
On 15May2019 2134, Gregory Szorc wrote:
PyPreConfig_INIT and PyConfig_INIT as macros that return a struct feel
weird to me.
On Thu, May 16, 2019 at 2:03 PM Victor Stinner wrote:
> (Le jeu. 16 mai 2019 à 06:34, Gregory Szorc a
> écrit :
> > > I know that the PEP is long, but well, it's a complex topic, and I
> > > chose to add many examples to make the API easier to understand.
> >
> > I saw your request for feedback
Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a écrit :
> > For unraisable hook, it's not hard to imagine other useful parameters
> > that can be passed to the hook to provide more context about the
> > exception. For example, right now we only pass one object. But there
> > are cases where a
On Thu, 16 May 2019 at 13:05, Victor Stinner wrote:
> > PyPreConfig_INIT and PyConfig_INIT as macros that return a struct feel
> > weird to me. Specifically, the `PyPreConfig preconfig =
> > PyPreConfig_INIT;` pattern doesn't feel right. I'm sort of OK with these
> > being implemented as macros.
(Le jeu. 16 mai 2019 à 06:34, Gregory Szorc a écrit :
> > I know that the PEP is long, but well, it's a complex topic, and I
> > chose to add many examples to make the API easier to understand.
>
> I saw your request for feedback on Twitter a few days back and found
> this thread.
>
> This PEP is
On Wed, 15 May 2019 13:00:16 -0700
Steve Dower wrote:
> On 15May2019 1248, Nathaniel Smith wrote:
> > I don't care about the deprecation either way. But can we fix the
> > individual decorators so both orders work? Even if it requires a special
> > case in the code, it seems worthwhile to
16.05.19 13:12, Victor Stinner пише:
I came to the UnraisableHookArgs structseq idea because of my bad
experience with extension warnings "hooks". Let me tell you this story
:-)
I know this story, because I followed these issues.
For unraisable hook, it's not hard to imagine other useful
After the detailed explanation, UnraisableHookArgs makes sense.
Forward-compatibility is important thing
On Thu, May 16, 2019 at 1:12 PM Victor Stinner wrote:
>
> Le jeu. 16 mai 2019 à 08:39, Serhiy Storchaka a écrit :
> >
> > 16.05.19 04:23, Victor Stinner пише:
> > > The first implementation
Le jeu. 16 mai 2019 à 08:39, Serhiy Storchaka a écrit :
>
> 16.05.19 04:23, Victor Stinner пише:
> > The first implementation of my API used sys.unraisablehook(exc_type,
> > exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
> > to add a new error message field which breaks
Le jeu. 16 mai 2019 à 04:44, Nathaniel Smith a écrit :
> What happens if the hook raises an exception?
Aha, thanks for asking the question!
If there is a custom hook and the hook fails, the default hook logs
the exception of the custom hook.
Technically, even if the default hook fails, the
16.05.19 04:23, Victor Stinner пише:
The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.
I modified my API to create an
39 matches
Mail list logo
