> I care only about builtin open()'s behavior.
> PEP 538 doesn't change default error handler of open().
>
> I think PEP 538 and PEP 540 should behave almost identical except
> changing locale
> or not. So I need very strong reason if PEP 540 changes default error
> handler of open().
>
I just ca
On Dec 6, 2017 21:14, "Guido van Rossum" wrote:
OK, then please just change the PEP's Version: header to 3.8.
Will do. Have a nice vacation! :)
-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
OK, then please just change the PEP's Version: header to 3.8.
On Wed, Dec 6, 2017 at 7:57 PM, Eric Snow
wrote:
>
>
> On Dec 6, 2017 20:31, "Guido van Rossum" wrote:
>
> If the point is just to be able to test the existing API better, no PEP is
> needed, right? It would be an unsupported, undocu
On Dec 6, 2017 20:31, "Guido van Rossum" wrote:
If the point is just to be able to test the existing API better, no PEP is
needed, right? It would be an unsupported, undocumented API.
In the short term that's one major goal. In the long term the
functionality provided by the PEP is a prerequis
If the point is just to be able to test the existing API better, no PEP is
needed, right? It would be an unsupported, undocumented API.
On Wed, Dec 6, 2017 at 7:22 PM, Nick Coghlan wrote:
> On 7 December 2017 at 12:46, Guido van Rossum wrote:
> > So you're okay with putting this off till (at le
On 7 December 2017 at 12:46, Guido van Rossum wrote:
> So you're okay with putting this off till (at least) 3.8? That sounds good
> to me, given that I'd like to go on vacation soon.
Eric reminded me off-list that we'd like to at least add the lower
level _interpreters API for the benefit of the
So you're okay with putting this off till (at least) 3.8? That sounds good
to me, given that I'd like to go on vacation soon.
On Wed, Dec 6, 2017 at 5:04 PM, Nick Coghlan wrote:
> On 7 December 2017 at 01:50, Guido van Rossum wrote:
> > Sorry to burst your bubble, but I have not followed any of
On 7 December 2017 at 01:50, Guido van Rossum wrote:
> Sorry to burst your bubble, but I have not followed any of the discussion
> and I am actually very worried about this topic. I don't think I will be
> able to make time for this before the 3.7b1 feature freeze.
I think that will be OK, as it
On 7 December 2017 at 08:20, Victor Stinner wrote:
> 2017-12-06 23:07 GMT+01:00 Antoine Pitrou :
>> One question: how do you plan to test for the POSIX locale?
>
> I'm not sure. I will probably rely on Nick for that ;-) Nick already
> implemented this exact check for his PEP 538 which is already
>
On 7 December 2017 at 01:59, Jakub Wilk wrote:
> * Nick Coghlan , 2017-12-06, 16:15:
>> The one that's relevant to default locale detection is just the string
>> that "setlocale(LC_CTYPE, NULL)" returns.
>
> POSIX doesn't require any particular return value for setlocale() calls.
> It's only guara
On Thu, 7 Dec 2017 00:22:52 +0100
Victor Stinner wrote:
> 2017-12-06 23:36 GMT+01:00 Antoine Pitrou :
> > Other than that, +1 on the PEP.
>
> Naoki doesn't seem to be confortable with the usage of the
> surrogateescape error handler by default for open(). Are you ok with
> that? If yes, would y
Here is the PR I've submitted:
https://github.com/python/cpython/pull/4699
The contract that I'm supporting (and, I think it can be argued, the only
reasonable contract in the intial implementation) is the following:
dtstr = dt.isoformat(*args, **kwargs)
dt_rt = datetime.fromisoformat(d
2017-12-06 23:36 GMT+01:00 Antoine Pitrou :
> Other than that, +1 on the PEP.
Naoki doesn't seem to be confortable with the usage of the
surrogateescape error handler by default for open(). Are you ok with
that? If yes, would you mind to explain why? :-)
Victor
___
On Wed, 6 Dec 2017 23:20:41 +0100
Victor Stinner wrote:
> 2017-12-06 23:07 GMT+01:00 Antoine Pitrou :
> > One question: how do you plan to test for the POSIX locale?
>
> I'm not sure. I will probably rely on Nick for that ;-) Nick already
> implemented this exact check for his PEP 538 which is
2017-12-06 23:07 GMT+01:00 Antoine Pitrou :
> One question: how do you plan to test for the POSIX locale?
I'm not sure. I will probably rely on Nick for that ;-) Nick already
implemented this exact check for his PEP 538 which is already
implemented in Python 3.7.
I already implemented the PEP 540
On Wed, 6 Dec 2017 01:49:41 +0100
Victor Stinner wrote:
> Hi,
>
> I knew that I had to rewrite my PEP 540, but I was too lazy. Since
> Guido explicitly requested a shorter PEP, here you have!
>
> https://www.python.org/dev/peps/pep-0540/
>
> Trust me, it's the same PEP, but focused on the most
Victor Stinner wrote:
Maybe the "UTF-8 Mode" should be renamed to "UTF-8 with
surrogateescape, or backslashreplace for stderr, or surrogatepass for
fsencode/fsencode on Windows, or strict for Strict UTF-8 Mode"... But
the PEP title would be too long, no? :-)
Relaxed UTF-8 Mode?
UTF8-Yeah-I'm-F
> On 26 Oct 2017, at 17:45, Chris Barker wrote:
>
> This is a key point that I hope is obvious:
>
> If an ISO string has NO offset or timezone indicator, then a naive datetime
> should be created.
>
> (I say, I "hope" it's obvious, because the numpy datetime64 implementation
> initially (an
Thanks! I’m personally comfortable with dropping support for systems that
people can’t buy support for, like IRIX, ULTRIX, SCO etc. It’s hard to
envision those being anything other than hobbyist platforms. Here at
Datalogics, we are selling and supporting software on HP-UX, for both pa-risc
On Wed, 6 Dec 2017 at 06:10 INADA Naoki wrote:
> >> And I have one worrying point.
> >> With UTF-8 mode, open()'s default encoding/error handler is
> >> UTF-8/surrogateescape.
> >
> > The Strict UTF-8 Mode is for you if you prioritize correctness over
> usability.
>
> Yes, but as I said, I cares
Hi Rob,
thanks for your patch. CPython core developers, as volunteers, have limited
resources available to maintain Python. Those resources are not only time, they
are also mental resources necessary to make a change in Python as well as
actual physical resources. Supporting a platform requires
* Nick Coghlan , 2017-12-06, 16:15:
Something I've just noticed that needs to be clarified: on Linux, "C"
locale and "POSIX" locale are aliases, but this isn't true in general
(e.g. it's not the case on *BSD systems, including Mac OS X).
For those of us with little to no BSD/MacOS experience, ca
Hello,
Back in June I was fired up to get my diverse set of platforms all running
Python 3, but quickly ran into issues and submitted a PR.
https://github.com/python/cpython/pull/2519
It seems as though this HP-UX specific change isn’t getting much consideration,
which probably isn’t a big dea
Sorry to burst your bubble, but I have not followed any of the discussion
and I am actually very worried about this topic. I don't think I will be
able to make time for this before the 3.7b1 feature freeze.
On Tue, Dec 5, 2017 at 6:51 PM, Eric Snow
wrote:
> Hi all,
>
> I've finally updated PEP 5
06.12.17 15:37, Paul Moore пише:
Behaviour (1) means that we'd get
>>> regex.sub(r'\w*', 'x', 'hello world', flags=regex.VERSION1)
'xx xx'
(because \w* matches the empty string after each word, as well as each
word itself). I just tested in Perl, and that is indeed what happens
there as well.
>> And I have one worrying point.
>> With UTF-8 mode, open()'s default encoding/error handler is
>> UTF-8/surrogateescape.
>
> The Strict UTF-8 Mode is for you if you prioritize correctness over usability.
Yes, but as I said, I cares about not experienced developer
who doesn't know what UTF-8 mode
On 6 December 2017 at 13:13, Serhiy Storchaka wrote:
> 05.12.17 22:26, Terry Reedy пише:
>>
>> On 12/4/2017 6:21 PM, MRAB wrote:
>>>
>>> I've finally come to a conclusion as to what the "correct" behaviour of
>>> zero-width matches should be: """always return the first match, but never a
>>> zero-
05.12.17 22:26, Terry Reedy пише:
On 12/4/2017 6:21 PM, MRAB wrote:
I've finally come to a conclusion as to what the "correct" behaviour
of zero-width matches should be: """always return the first match, but
never a zero-width match that is joined to a previous zero-width
match""".
Is this d
On 6 December 2017 at 20:38, Victor Stinner wrote:
> Nick:
>> So if PEP 540 is going to implicitly trigger switching encodings, it
>> needs to specify whether it's going to look for the C locale or the
>> POSIX locale (I'd suggest C locale, since that's the actual default
>> that causes problems).
05.12.17 01:21, MRAB пише:
I've finally come to a conclusion as to what the "correct" behaviour of
zero-width matches should be: """always return the first match, but
never a zero-width match that is joined to a previous zero-width match""".
If it's about to return a zero-width match that's jo
Nick:
> So if PEP 540 is going to implicitly trigger switching encodings, it
> needs to specify whether it's going to look for the C locale or the
> POSIX locale (I'd suggest C locale, since that's the actual default
> that causes problems).
I'm thinking at the test already used by check_force_asc
Hi Naoki,
2017-12-06 5:07 GMT+01:00 INADA Naoki :
> Oh, revised version is really short!
>
> And I have one worrying point.
> With UTF-8 mode, open()'s default encoding/error handler is
> UTF-8/surrogateescape.
The Strict UTF-8 Mode is for you if you prioritize correctness over usability.
In the
Let's discuss -Xdev implementation issue at
https://bugs.python.org/issue32230
In short, -Xdev must add its warning at the end to respect BytesWarning,
whereas it's not possible with -W option :-(
Victor
Le 6 déc. 2017 09:15, "Nick Coghlan" a écrit :
On 6 December 2017 at 14:50, Nick Coghlan
On 6 December 2017 at 14:50, Nick Coghlan wrote:
> On 6 December 2017 at 14:34, Nick Coghlan wrote:
>> That said, I go agree we could offer easier to use APIs to app
>> developers that just want to hide warnings from their users, so I've
>> filed https://bugs.python.org/issue32229 to propose a st
On Dec 5, 2017 23:49, "Nick Coghlan" wrote:
Nice updates! I like this version.
Great! :)
My one suggestion here would be to consider a dedicated exception type
like "interpreters.SubinterpreterError", rather than re-using
RuntimeError directly. That way you can put the extracted traceback on
a
35 matches
Mail list logo
