There is an idiomatic Python code:
do_something()
try:
do_something_other()
except:
undo_something()
raise
If an error is raised when execute do_something_other(), then we should
first restore the state that was before calling do_something(), and then
rerais
On 12/06/2017, Serhiy Storchaka wrote:
>
> But if an error is raised when execute undo_something(), it replaces the
> original exception which become chaining as the __context__ attribute.
> The problem is that this can change the type of the exception. If
> do_something_other() raises SystemExit
On 12 June 2017 at 17:10, Serhiy Storchaka wrote:
> Does it mean that we should rewrite every chunk of code similar to the
> above? And if such cumbersome code is necessary and become common, maybe it
> needs syntax support in the language? Or changing the semantic of exceptions
> raised in error
Thanks for replying to my points!
On 12/06/2017, Nick Coghlan wrote:
>
> `PYTHONIOENCODING=:strict` remains the preferred way of forcing strict
> encoding checks on the standard streams, regardless of locale.
Then the user of my script has to care that it's written in Python and
set that specifi
On 12 June 2017 at 17:31, Martin (gzlist) via Python-Dev
wrote:
> On 12/06/2017, Serhiy Storchaka wrote:
>>
>> But if an error is raised when execute undo_something(), it replaces the
>> original exception which become chaining as the __context__ attribute.
>> The problem is that this can change
> On 12/06/2017, Nick Coghlan wrote:
>>
>> `PYTHONIOENCODING=:strict` remains the preferred way of forcing strict
>> encoding checks on the standard streams, regardless of locale.
>
> Then the user of my script has to care that it's written in Python and
> set that specifically in their crontab or
Hi,
Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
forward to UTF-8 everywhere ;-)
I would prefer to not be annoyed by warning messages about encodings
at startup if possible:
"Python detected LC_CTYPE=C: LC_CTYPE coerced to C.UTF-8 (set another
locale or PYTHONCOERCECLOC
On Mon, 12 Jun 2017 10:56:31 +0200
Victor Stinner wrote:
> Hi,
>
> Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
> forward to UTF-8 everywhere ;-)
>
> I would prefer to not be annoyed by warning messages about encodings
> at startup if possible:
>
> "Python detected LC_
On Mon, Jun 12, 2017 at 5:56 PM, Victor Stinner
wrote:
> Hi,
>
> Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
> forward to UTF-8 everywhere ;-)
>
> I would prefer to not be annoyed by warning messages about encodings
> at startup if possible:
>
> "Python detected LC_CTYPE
2017-06-12 11:35 GMT+02:00 INADA Naoki :
> I think "Good practice" is set `LC_CTYPE=C.UTF-8` environment variable,
> as warning says.
I like using LANG=C to display a manual page in english. Technically,
I know that it's wrong, but it works. I don't see the point of the
warning. I'm able to render
On 12 June 2017 at 17:47, Martin (gzlist) wrote:
> Thanks for replying to my points!
>
> On 12/06/2017, Nick Coghlan wrote:
>>
>> `PYTHONIOENCODING=:strict` remains the preferred way of forcing strict
>> encoding checks on the standard streams, regardless of locale.
>
> Then the user of my script
On 12 June 2017 at 18:56, Victor Stinner wrote:
> Hi,
>
> Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
> forward to UTF-8 everywhere ;-)
>
> I would prefer to not be annoyed by warning messages about encodings
> at startup if possible:
>
> "Python detected LC_CTYPE=C: LC_
On 12 June 2017 at 14:24, Nick Coghlan wrote:
> On 12 June 2017 at 18:56, Victor Stinner wrote:
>> Hi,
>>
>> Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
>> forward to UTF-8 everywhere ;-)
>>
>> I would prefer to not be annoyed by warning messages about encodings
>> at s
On Mon, Jun 12, 2017 at 6:46 PM, Victor Stinner
wrote:
> 2017-06-12 11:35 GMT+02:00 INADA Naoki :
>> I think "Good practice" is set `LC_CTYPE=C.UTF-8` environment variable,
>> as warning says.
>
> I like using LANG=C to display a manual page in english.
Me too. But we can use LC_CTYPE=C.UTF-8 wi
> Yury in the comment for PR 2108 [1] suggested more complicated code:
>
> do_something()
> try:
> do_something_other()
> except BaseException as ex:
> try:
> undo_something()
> finally:
> raise ex
And this is still bad, because it loses
2017-06-12 15:28 GMT+02:00 INADA Naoki :
>> I like using LANG=C to display a manual page in english.
>
> Me too. But we can use LC_CTYPE=C.UTF-8 with LANG=C.
My point is that LANG=C is easy to remember and "it just works".
> And LC_CTYPE=C.UTF-8 is much easier (and ideal) than
> PYTHONLOCALECOER
On 06/12/2017 05:24 AM, Nick Coghlan wrote:
I suspect the eventual outcome is going to be dropping that particular
warning (since it's been problematic for Fedora's 3.6 backport as
well, and the problems are due to the warning itself, *not* the locale
coercion), but I'd prefer to keep the notifi
FYI I started to work on the implementation: I rebased Alex Gaynor's
patch written in 2014 and converted it to a pull request.
http://bugs.python.org/issue22559
Victor
2017-06-10 1:56 GMT+02:00 Benjamin Peterson :
> The reason we're having this conversation at all is probably a matter of
> timing
On Mon, Jun 12, 2017 at 5:25 AM Nick Coghlan wrote:
> On 12 June 2017 at 18:56, Victor Stinner wrote:
> > Hi,
> >
> > Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
> > forward to UTF-8 everywhere ;-)
> >
> > I would prefer to not be annoyed by warning messages about enco
On Mon, 12 Jun 2017 at 01:08 Nick Coghlan wrote:
> On 12 June 2017 at 17:31, Martin (gzlist) via Python-Dev
> wrote:
> > On 12/06/2017, Serhiy Storchaka wrote:
> >>
> >> But if an error is raised when execute undo_something(), it replaces the
> >> original exception which become chaining as the
>> -1 for disable coercion by default: It's too unhelpful for beginners.
>
> Are you proposing to reject the PEP that you approved? Now I'm confused.
>
No, I just wanted to clarify your propose.
You said "I'm able to render my hello world with the wrong locale :-)".
So I want to clarify you didn
On 6/12/2017 5:35 AM, INADA Naoki wrote:
On Mon, Jun 12, 2017 at 5:56 PM, Victor Stinner
wrote:
Hi,
Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
forward to UTF-8 everywhere ;-)
I would prefer to not be annoyed by warning messages about encodings
at startup if possibl
On 12 June 2017 at 21:11, Terry Reedy wrote:
> I do not see this with my fresh 3.7 repository debug build on my Win 10
> machine. If I did, I would be -1000. This warning should be treated
> as a deprecation warning, off by default.
My understanding is that this is a Unix-only change. If it aff
On 6/12/2017 1:11 PM, Terry Reedy wrote:
I do not have any locale-related env vars. You should check whether
the warning is off on all Win10 systems, as well as Win7 and Win8.
Many Windows users know nothing about ENV VARS, and even if they do,
they may not know how (I don't know the details)
On Jun 12, 2017 10:50, "Gregory P. Smith" wrote:
The problem, as with all warnings, is that it isn't the user who has
control over the problem who sees the warning. It is the end use of an
application on a system that sees it.
I don't think I understand the distinction you're making here. This
On Mon, Jun 12, 2017 at 1:48 PM Nathaniel Smith wrote:
> On Jun 12, 2017 10:50, "Gregory P. Smith" wrote:
>
>
> The problem, as with all warnings, is that it isn't the user who has
> control over the problem who sees the warning. It is the end use of an
> application on a system that sees it.
>
On Mon, Jun 12, 2017 at 6:29 AM, Stefan Ring wrote:
>
> > Yury in the comment for PR 2108 [1] suggested more complicated code:
> >
> > do_something()
> > try:
> > do_something_other()
> > except BaseException as ex:
> > try:
> > undo_something()
> >
An update on 3.6.2rc1: we have been working through a few critical and release
blocker issues that needed to be fixed for 3.6.2. Thanks to everyone who has
helped with them! At the moment, we have one security-related release blocker
(http://bugs.python.org/issue29591) which I think we need to
On Mon, Jun 12, 2017 at 1:07 AM, Nick Coghlan wrote:
> Aye, agreed. The key challenge we have is that we're trying to
> represent the exception state as a linked list, when what we really
> have once we start taking cleanup errors into account is an exception
> *tree*.
[...]
> P.S. trio's MultiErr
On 13 June 2017 at 06:58, Gregory P. Smith wrote:
> I guess so. It is a system environment configuration problem. But I'd still
> imagine that end users never touch their LANG or LC_* environment variables
> themselves. (the only time I touch anything is to explicitly set LANG=C on
> occasion whe
30 matches
Mail list logo
