Hi,
I rejected my own PEP 510 "Specialize functions with guards" that I
wrote in January 2016:
https://github.com/python/peps/commit/c99fb8bf5b5c16c170e1603a1c66a74e93a4ae84
"This PEP was rejected by its author since the design didn't show any
significant speedup, but also because of the lack of
Hi,
I rejected my own PEP 511 "API for code transformers" that I wrote in
January 2016:
https://github.com/python/peps/commit/9d8fd950014a80324791d7dae3c130b1b64fdace
Rejection Notice:
"""
This PEP was rejected by its author.
This PEP was seen as blessing new Python-like programming languages
2017-10-17 22:25 GMT+02:00 Guido van Rossum :
> It takes courage to admit failures like this! I think this is a good call.
> It echoes the experiences with Unladen Swallow and Pyston. Despite what
> people may think, CPython really isn't slow, given the large set of
> constraints on the implementat
Antoine Pitrou:
> Why not ``time.process_time_ns()``?
I measured the minimum delta between two clock reads, ignoring zeros.
I tested time.process_time(), os.times(), resource.getrusage(), and
their nanosecond variants (with my WIP implementation of the PEP 564).
Linux:
* process_time_ns(): 1 ns
10-18 0:05 GMT+02:00 Victor Stinner :
> Antoine Pitrou:
>> Why not ``time.process_time_ns()``?
>
> I measured the minimum delta between two clock reads, ignoring zeros.
> I tested time.process_time(), os.times(), resource.getrusage(), and
> their nanosecond variants (with my WIP
Hi,
Since the beginning of the year, I'm working on a tool to track if all
security vulnerabilities are fixed in all Python maintained versions
(versions still accepting security fixes):
http://python-security.readthedocs.io/vulnerabilities.html
Currently, five branches are maintained: 2.7, 3
Le 21 oct. 2017 20:31, "francismb" a écrit :
I understand that one can just multiply/divide the nanoseconds returned,
(or it could be a factory) but wouldn't it help for future enhancements
to reduce the number of functions (the 'pico' question)?
If you are me to predict the future, I predict t
Le 22 oct. 2017 17:06, "Wes Turner" a écrit :
Must they always use their own implementations of time., datetime.
__init__, fromordinal, fromtimestamp ?!
Yes, exactly.
Note: Adding resolution better than 1 us to datetime is not in the scope of
the PEP but there is an issue, open since a long ti
Thanks Thomas, it was interesting! You confirmed that time.time_ns() and
other system clocks exposed by Python are inappropriate for sub-nanosecond
physical experiment.
By the way, you mentionned that clocks are not synchronized. That's another
revelant point. Even if system clocks are synchronize
2017-10-24 11:22 GMT+02:00 Antoine Pitrou :
> What does synchronization have to do with it? If synchronization
> matters, then your PEP should be rejected, because current computers
> using NTP can't synchronize with a better precision than 230 ns.
Currently, the PEP 564 is mostly designed for ha
Warning: the PEP 564 doesn't make any assumption about clock
synchronizations. My intent is only to expose what the operating
system provides without losing precision. That's all :-)
2017-10-24 13:25 GMT+02:00 Antoine Pitrou :
> NTP is layered over UDP. The article shows base case UDP latencies o
Hi,
We are using Mailman 3 for the new buildbot-status mailing list and it
works well:
https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
I prefer to read archives with this UI, it's simpler to follow
threads, and it's possible to reply on the web UI!
To be honest, we got som
2017-10-26 12:01 GMT+02:00 Antoine Pitrou :
> Is it possible to have a
> pipermail-style UI as an alternative?
I don't know pipermail. Do you have an example?
I don't think that Mailman 3 gives the choice of the UI for archives.
I didn't ask anyone to write a new software. I only proposed to use
2017-10-26 12:01 GMT+02:00 Antoine Pitrou :
>> We are using Mailman 3 for the new buildbot-status mailing list and it
>> works well:
>>
>> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
>>
>> I prefer to read archives with this UI, it's simpler to follow
>> threads, and it'
2017-10-27 10:17 GMT+02:00 Stefan Krah :
> Victor wrote a patch and would like to avoid adding a (probably unnecessary)
> emulation function. I agree with that.
> (...)
> So if any platform does not have some form of aligned_alloc(), please
> speak up.
I'm not really opposed to implement an aligne
(Email resent, I first sent it to Nick privately by mistake.)
2017-11-02 2:53 GMT+01:00 Nick Coghlan :
> The piece that we're currently missing to make such workflows easier to
> manage is an equivalent of JavaScript's source maps (...)
Code objects already have a instruction pointer => line numb
Thank you Guido for your review and approval.
I just implemented the PEP 564 and so changed the PEP status to Final.
FYI I also added 3 new clock identifiers to the time module in Python
3.7: CLOCK_BOOTTIME, CLOCK_PROF and CLOCK_UPTIME.
So you can now get your Linux uptime with a resolution of 1
Hi,
2017-11-03 15:36 GMT+01:00 Guido van Rossum :
> Maybe we should remove typing from the stdlib?
> https://github.com/python/typing/issues/495
I'm strongly in favor on such move.
My experience with asyncio in the stdlib is that users expect changes
faster than the very slow release process of
2017-11-03 18:00 GMT+01:00 Steve Dower :
> If not having typing installed means you can't use "Any" or "Optional" in an
> annotation, that basically kills the whole thing. Some primitives need to be
> there.
I'm not sure that I understand you.
The question is if you would only need or .
If typi
2017-11-04 0:44 GMT+01:00 Joao S. O. Bueno :
> This just popped up in Brython's issue tracker discussion:
>
> """
> Pierre Quentel
>
> 04:57 (16 hours ago)
> to brython-dev/br., Subscribed
>
> I think it's better to rename all occurences of async now, although
> it's strange that :
>
> there is cu
2017-11-06 8:47 GMT+01:00 Serhiy Storchaka :
> 06.11.17 09:09, Guido van Rossum пише:
>>
>> I still find this unfriendly to users of Python scripts and small apps who
>> are not the developers of those scripts. (Large apps tend to spit out so
>> much logging it doesn't really matter.)
>>
>> Isn't t
2017-11-05 18:50 GMT+01:00 Guido van Rossum :
> I don't see this as a reason to not put this into the language spec at 3.7.
It can prevent some kinds of optimizations. Dictionaries are used
"everywhere" in Python, so they are very important for performance.
I would prefer to only keep the orderin
Hi,
While discussions on the typing module are still hot, what do you
think of allowing annotations in the standard libraries, but limited
to a few basic types:
* None
* bool, int, float, complex
* bytes, bytearray
* str
I'm not sure about container types like tuple, list, dict, set,
frozenset.
that the overhead is negligible, especially when using python3 -OO.
Victor
2017-11-06 17:02 GMT+01:00 Victor Stinner :
> Hi,
>
> While discussions on the typing module are still hot, what do you
> think of allowing annotations in the standard libraries, but limited
> to a few basic typ
Hi,
I see more and more proposed changes to fix some parts of the code to
"partially" support a platform.
I remember that 5 years ago, the CPython code was "full" of #ifdef and
other conditional code to support various platforms, and I was happy
when we succeeded to remove support for all these o
2017-11-06 22:24 GMT+01:00 Antoine Pitrou :
> We support POSIX-compatible platforms. Do OpenBSD and NetBSD need
> special care?
Aha, "POSIX", you are funny Antoine :-D
If it was a single #ifdef in the whole code base, I wouldn't have to
start such thread on python-dev :-)
Open issues with "Ope
2017-11-06 22:16 GMT+01:00 Steve Dower :
> I don't believe CPython *partially* supports any platforms - either they are
> fully supported or they are not supported.
Ok. So there are two questions:
* Where is the list of platforms "endorsed" by CPython ("fully supported")
* How can we decide when
2017-11-06 23:07 GMT+01:00 Antoine Pitrou :
> The reason that testing on
> them is interesting, IMHO, is to chase potential Linux-isms in our code
> base. Circumventing {Free,Open,Net}BSD-specific deficiences is not.
Serhiy found at least an interesting issue thanks to OpenBSD, a bug in
memory de
2017-11-07 0:41 GMT+01:00 Serhiy Storchaka :
> Several month ago there was a couple of buildbots including NetBSD and
> OpenBSD. What happened to them? Was the support of NetBSD and OpenBSD
> officially stopped as well as the support of OpenIndiana?
While I don't recall seeing any NetBSD buildbot,
I like these macros!
Technically, would it be possible to use an inline function instead of
a macro for Python 3.7?
Victor
2017-11-08 17:30 GMT+01:00 Serhiy Storchaka :
> Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all
> maintained versions ([1] and [2]). Despite the
Recently, Oren Milman fixed multiple bugs when an __init__() method
was called twice. IMHO Py_SETREF() was nicely used in __init__():
https://github.com/python/cpython/commit/e56ab746a965277ffcc4396d8a0902b6e072d049
https://github.com/python/cpython/commit/c0cabc23bbe474d542ff8a4f1243f4ec3cce5549
2017-11-09 3:08 GMT+01:00 Raymond Hettinger :
> I greatly prefer putting all the decrefs at the end to increase my confidence
> that it is okay to run other code that might reenter the current code.
There are 3 patterns to update C attributes of an object:
(1)
Py_XDECREF(obj->attr); // can call
Hum, to give more context to the discussion, the two discussed macros
are documented this way:
#ifndef Py_LIMITED_API
/* Safely decref `op` and set `op` to `op2`.
*
* As in case of Py_CLEAR "the obvious" code can be deadly:
*
* Py_DECREF(op);
* op = op2;
*
* The safe way is:
*
*
I didn't follow the discussion on the PEP but I was surprised to read "from
__future__ import annotations" in an example. Annotations exist since
Python 3.0, why would Python 3.7 require a future for them? Well, I was
aware of the PEP, but I was confused anyway.
I really prefer "from __future__ im
Hi,
The discussion on DeprecationWarning reminded me my old idea of a
"development mode" for CPython: -X dev. Since Brett likes it, I post
it on python-dev. Last year, I posted this idea to python-ideas but my
idea was rejected:
https://mail.python.org/pipermail/python-ideas/2016-March/039314.htm
> The change proposed in this PEP is to update the default warning filter list
> to be::
>
> default::DeprecationWarning:__main__
> ignore::DeprecationWarning
> ignore::PendingDeprecationWarning
> ignore::ImportWarning
> ignore::BytesWarning
> ignore::ResourceWarning
This P
Hi,
I'm not convinced that this PEP 565 will prevent developers to be
surprised when upgrading Python, since more and more applications are
using an entry point: an import + a single function call. For example,
*all* OpenStack applications use an entry point and so will be
unaffected by this PEP.
2017-11-13 17:40 GMT+01:00 Antoine Pitrou :
> I would personally not add `-b` in those options. I think it was
> useful while porting stuff to 3.x, but not so much these days.
You should consider youself as lucky if you completed to port all your
code to Python 3. It's not my case yet :-) (I'm th
2017-11-13 17:51 GMT+01:00 Antoine Pitrou :
> The main issue I have with `-b` is actually that you can get spurious
> warnings about properly working code. You can also get warnings in
> well-tested third-party libraries, e.g.:
>
> distributed/tests/test_client.py::test_get_versions
>
> /home/a
Hi,
Since Brett and Nick like the idea and nobody complained against it, I
implemented the -X dev option:
https://bugs.python.org/issue32043
(Right now, it's a pull request.)
I removed the -b option.
Victor
2017-11-14 3:57 GMT+01:00 Nick Coghlan :
> On 14 November 2017 at 02:08, Victor
Ok, I merged my PR adding -X dev: you can now test in Python 3.7 ;-)
> The list of checks can be extended later. For example, we may enable
> the debug mode of asyncio: PYTHONASYNCIODEBUG=1.
I opened https://bugs.python.org/issue32047 to propose enable asyncio
debug mode using the Python develope
2017-11-16 13:09 GMT+01:00 Antoine Pitrou :
>> What do you think? Is it ok to include asyncio in the global "developer
>> mode"?
>
> I'd rather not. Those are two orthogonal things. In particular,
> asyncio debug mode is quite expensive.
Is it really an issue? When you develop an application, t
2017-11-16 13:11 GMT+01:00 Antoine Pitrou :
> Could you measure and perhaps document the expected effect on
> performance and memory consumption?
> (it can be a very rough ballpart estimate)
Currently "python3 -X dev script.py" behaves as "PYTHONMALLOC=debug
python3 -W default -X faulthandler scri
2017-11-16 13:43 GMT+01:00 Antoine Pitrou :
>> About asyncio debug mode, if it's too expensive to be used to develop
>> an application, maybe there is an issue with additional checks? Should
>> we remove some of them to be able to use asyncio debug mode in more
>> cases?
>
> Well, I'm sure some peo
2017-11-16 13:54 GMT+01:00 Antoine Pitrou :
> -Wdefault means -Wonce or -Walways? If the former, I don't expect many
> warnings to be emitted.
It's kind of funny that passing "-W default" changes the "default"
behaviour. "-W default" is documented as:
"Explicitly request the default behavior (
2017-11-16 15:47 GMT+01:00 Yury Selivanov :
> Overall I don't see an issue with enabling asyncio debug mode when
> python is executed with "-X dev".
Cool!
> If the purpose of the flag is to
> make Python super verbose and it will not be recommended to use it in
> production -- then why not.
Runn
ot the infamous -d option!
Honestly, I never used __debug__ nor sys.flags.debug.
I like adding yet another option to confuse people a little bit more!
Victor
2017-11-16 17:52 GMT+01:00 Antoine Pitrou :
>
> Le 16/11/2017 à 17:42, Victor Stinner a écrit :
>>
>> Running an appli
Hi,
The CPython internals evolved during Python 3.7 cycle. I would like to
know if we broke the C API or not.
Nick Coghlan and Eric Snow are working on cleaning up the Python
initialization with the "on going" PEP 432:
https://www.python.org/dev/peps/pep-0432/
Many global variables used by the "
Hi,
tl; dr I propose to extend the existing "stable API" to make it almost
as complete as the current API. For example, add back
PyTuple_GET_ITEM() to be stable API, but it becomes a function call
rather than a macro. The final question is if it's not too late to
iterate on an implementation of th
Hi,
I noticed that Python not only hides DeprecationWarning, but also
PendingDeprecationWarning and ImportWarning by default. While I
understand why we decided to hide these warnings to users for a Python
compiled in release mode, why are they hidden in Python debug builds?
I'm asking the questio
Le 18 nov. 2017 08:32, "Serhiy Storchaka" a écrit :
Making PyTuple_GET_ITEM() a function will destroy the half of the benefit.
And this will make the ABI larger.
Sorry if I wasn't explicit about it: my idea of changing the API has an
obvious impact on performance. That's why the first step on t
Le 18 nov. 2017 10:44, "Serhiy Storchaka" a écrit :
The simplest way to do this:
#define PyTuple_GET_ITEM PyTuple_GetItem
This will not add new names to ABI. Such defines can be added in a separate
header file included for compatibility.
It is exactly what I am proposing :-)
Victor
_
ed here.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.
> stinner%40gmail.com
>
___
To not lost track of the issue, I created this issue on the bpo:
https://bugs.python.org/issue32086
Victor
2017-11-20 7:54 GMT+01:00 Nick Coghlan :
> On 19 November 2017 at 18:52, Victor Stinner wrote:
>> Maybe we can find a compromise: revert the change on memory allocators. They
&
2017-11-18 18:13 GMT+01:00 Brett Cannon :
> +1 from me as well.
Ok, I created https://bugs.python.org/issue32088 and
https://github.com/python/cpython/pull/4474 to implement the proposed
change.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
h
2017-11-20 16:31 GMT+01:00 Eric Snow :
> That Py_DecodeLocale() can use PyMem_RawMalloc() pre-init is an
> implementation detail.
Py_DecodeLocale() uses PyMem_RawMalloc(), and so its result must be
freed by PyMem_RawFree(). It's part the documentation.
I'm not sure that I understood correctly. D
Oh, that was quick. Thanks!
I counted Serhiy, Barry, Nick, you and me in favor of the change, and
nobody against the code. So well, it's ok to merge it :-)
Victor
2017-11-20 18:49 GMT+01:00 Lukasz Langa :
> Merged. Thanks! ✨ 🍰 ✨
>
> - Ł
>
>> On Nov 20, 2017, at 7:01 AM
2017-11-20 22:35 GMT+01:00 Eric Snow :
> I'm okay with that if we can't find another way. However, shouldn't
> we be able to statically initialize the raw allocator in _PyRuntime,
> much as we were doing before in obmalloc.c? I have a rough PR up:
>
> https://github.com/python/cpython/pull/44
2017-11-21 16:57 GMT+01:00 Eric Snow :
>> I understand that moving global variables to _PyRuntime helps to
>> clarify how these variables are initialized and then finalized, but
>> memory allocators are a complex corner case.
>
> Agreed. I spent a large portion of my time getting the allocators
>
2017-11-22 12:04 GMT+01:00 Antoine Pitrou :
> IMHO this really needs a simple solution documented somewhere. Also,
> hopefully when you do the wrong thing, you get a clear error message to
> know how to fix your code?
Right now, calling PyMem_RawMalloc() before calling
_PyRuntime_Initialize() cal
Aha, contextlib.nullcontext() was just added, cool!
https://github.com/python/cpython/commit/0784a2e5b174d2dbf7b144d480559e650c5cf64c
https://bugs.python.org/issue10049
Victor
2017-09-09 21:54 GMT+02:00 Victor Stinner :
> I always wanted this feature (no kidding).
>
> Would it be po
() is just not
possible, since it's a private API which is not exported...
Victor
2017-11-18 1:01 GMT+01:00 Victor Stinner :
> Hi,
>
> The CPython internals evolved during Python 3.7 cycle. I would like to
> know if we broke the C API or not.
>
> Nick Coghlan and Eric Sn
I proposed a PR to explicitly list functions safe to be called before
Py_Initialize():
https://bugs.python.org/issue32124
https://github.com/python/cpython/pull/4540
I found more than 11 functions.. I also found variables ;-)
Victor
2017-11-24 5:01 GMT+01:00 Nick Coghlan :
> On 24 November
Hi,
Serhiy opened this thread after I removed tools for CVS and Subversion from
the master branch: two scripts and a svnmap.txt file. I removed
Misc/svnmap.txt, a mapping of Subversion commits to Mercurial commits. The
change was approved by 3 core dev, but then I was asked to restore (only)
the s
2017-11-12 10:24 GMT+01:00 Nick Coghlan :
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
I understand the rationale of the PEP, but I dislike the proposed
implementation.
Hi,
CPython has many C extensions with non-trivial PyInit_xxx() functions
which has to handle failures. A few modules use "Py_DECREF(m); retutrn
NULL;", but most functions only do "return NULL;". Is it a reference
leak or not?
Example from Modules/posixmodule.c:
v = convertenviron();
Py_
Link for lazy people like me:
https://www.python.org/dev/peps/pep-0562/
I changed the PEP status to fix a typo in the abstract:
https://github.com/python/peps/commit/a87417b22bf15bc4382daeaef6d32886c687ad19
Victor
2017-12-04 17:58 GMT+01:00 Guido van Rossum :
> Ivan,
>
> Congrats on your PEP. I
Hi,
Stéphane Wirtel gave a talk last month at Pycon CA about CPython pull
requests. His slides:
https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests
He produced interesting statistics that we didn't have before on pull
requests (PR), from February 2017 to October 2017:
* total
ted as the BDFL-Delegate.
https://www.python.org/dev/peps/pep-0540/
Full-text below.
Victor
PEP: 540
Title: Add a new UTF-8 mode
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner ,
Nick Coghlan
BDFL-Delegate: INADA Naoki
Status: Draft
Type: Standards Track
Content-Type: text/x
2017-12-05 16:50 GMT+01:00 Guido van Rossum :
> Honestly, I didn't completely follow what Victor thinks of the PEP -- his
> post seemed mostly about promoting his own -X dev flag.
-X dev is similar (but different) than -W default: show warnings which
are hidden by default otherwise. -W default wor
2017-12-05 19:24 GMT+01:00 Guido van Rossum :
>> I disagree that *users* of an application is supposed to "handle"
>> deprecation warnings: report them to the developer, or even try to fix
>> them. IHMO these warnings (hidden by default) were introduced for
>> developers of the application.
>
> But
2017-12-05 21:21 GMT+01:00 Serhiy Storchaka :
> 05.12.17 22:10, Victor Stinner пише:
>>
>> Maybe we need something to declare the code that we own, to
>> enable warnings on them.
>
> Just compare __author__ with the name of the user running a script. ;-)
I was
2017-12-05 22:18 GMT+01:00 Guido van Rossum :
> So I guess PEP acceptance week is over. :-(
My bad, Barry wrote "PEP Acceptance Day", not week, on twitter ;-)
https://twitter.com/pumpichank/status/937770805076905990
Victor
___
Python-Dev mailing list
Py
Chris:
> I just took another look at 538 -- and yes, the relationship between the two
> is really unclear. In particular, with 538, why do we need 540? I honestly
> don't know.
The PEP 538 only impacts platforms which provide the C.UTF-8 locale or
a variant: only a few recent Linux distribution. I
below.
Victor
PEP: 540
Title: Add a new UTF-8 mode
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
BDFL-Delegate: INADA Naoki
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 5-January-2016
Python-Version: 3.7
Abstract
Add a new UTF-8 mode to i
> Annex: Differences between the PEP 538 and the PEP 540
> ==
>
> The PEP 538 uses the "C.UTF-8" locale which is quite new and only
> supported by a few Linux distributions; this locale is not currently
> supported by FreeBSD or macOS for example.
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
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
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
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
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
___
While I'm not strongly convinced that open() error handler must be
changed for surrogateescape, first I would like to make sure that it's
really a very bad idea because changing it :-)
2017-12-07 7:49 GMT+01:00 INADA Naoki :
> I just came up with crazy idea; changing default error handler of open
2017-12-06 5:07 GMT+01:00 INADA Naoki :
> And opening binary file without "b" option is very common mistake of new
> developers. If default error handler is surrogateescape, they lose a chance
> to notice their bug.
To come back to your original point, I didn't know that it was a
common mistake t
2017-12-08 0:26 GMT+01:00 Guido van Rossum :
> You will quickly get decoding errors, and that is INADA's point. (Unless you
> use encoding='Latin-1'.) His worry is that the surrogateescape error handler
> makes it so that you won't get decoding errors, and then the failure mode is
> much harder to
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
BDFL-Delegate: INADA Naoki
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 5-January-2016
Python-Version: 3.7
Abstract
Add a new UTF-8 mode to ignore the locale, use the UTF-8 encoding, and
change ``
Hi,
Oh, locale.getpreferredencoding(), that's a good question :-)
2017-12-08 6:02 GMT+01:00 INADA Naoki :
> But I want to clarify more about difference/relationship between PEP
> 538 and 540.
>
> If I understand correctly:
>
> Both of PEP 538 (locale coercion) and PEP 540 (UTF-8 mode) shares
> sa
2017-12-08 6:11 GMT+01:00 INADA Naoki :
> Or should we change loale.getpreferredencoding() to return UTF-8
> instead of ASCII always, regardless of PEP 538 and 540?
On the POSIX locale, if the locale coercion works (PEP 538),
locale.getpreferredencoding() returns UTF-8. We are good.
The question
2017-12-08 15:01 GMT+01:00 INADA Naoki :
>> In short, locale coercion and UTF-8 mode will be both enabled by the
>> POSIX locale.
>
> Hm, it is bit surprising because I thought UTF-8 mode is fallback
> of locale coercion when coercion is failed or disabled.
I rewrote the "differences between the P
as very helpful
and I really like how the PEP evolves!
IMHO the PEP 540 version 4 is just perfect and ready for
pronouncement! (... until someone finds another flaw, obviously!)
Victor
2017-12-08 13:58 GMT+01:00 Victor Stinner :
> 2017-12-08 6:11 GMT+01:00 INADA Naoki :
>> Or should
2017-12-08 16:22 GMT+01:00 Victor Stinner :
> I updated my PEP: in the 4th version, locale.getpreferredencoding()
> now returns 'UTF-8' in the UTF-8 Mode.
Sorry, I forgot to mention that I already updated the implementation
to the latest version of the PEP:
https://github.com/pyt
2017-12-08 17:29 GMT+01:00 Ethan Furman :
> For those of us trying to follow along, is this change to open() one that
> Inada-san was worried about? Has something else changed?
I agree that my PEP is evolving quickly, that's why I added a "Version
History" at the end:
https://www.python.org/dev/p
Hi,
Le 10 déc. 2017 05:48, "INADA Naoki" a écrit :
Now I'm OK to accept the PEP, except one nitpick.
I got a private email about the same issue. I don't think that it's
nitpicking since many people were confused about the relationship between
the PEP 538 and PEP 540. So it seems like I was con
Ok, I fixed the effects of the locale coercion (PEP 538). Does it now
look good to you, Naoki?
https://www.python.org/dev/peps/pep-0540/#relationship-with-the-locale-coercion-pep-538
The commit:
https://github.com/python/peps/commit/71cda51fbb622ece63f7a9d3c8fa6cd33ce06b58
diff --git a/pep-0540
2017-12-10 18:46 GMT+01:00 INADA Naoki :
> Except one typo I commented on Github,
Fixed:
https://github.com/python/peps/commit/08224bf6bdf16b539fb6f8136061877e5924476d
> I accept PEP 540.
Wow, thank you :-) Again, thank you for your very useful feedback
which helped to make the PEP 540 much bet
Xavier is working on fixing random issues specific to Android since 2
years. He is almost done, the last step is just to add a build infra to get
a buildbot.
https://github.com/python/cpython/pull/1629
https://bugs.python.org/issue30386
It's a set of scripts to cross compile Python from Linux to
Le 10 déc. 2017 23:10, "Ned Deily" a écrit :
> But on the other, it does add a large non-zero burden to all core
developers (...)
I reviewed some of the Android' pull requests. Most changes are small and
self contained.
> As long as Xavier is willing to keep supporting the platform, the first
re
2017-12-10 15:19 GMT+01:00 Xavier de Gaye :
> Motivations
> ===
>
> * Android is ubiquitous.
> * This would be the first platform supported by Python that is
> cross-compiled,
> thanks to many contributors.
> * Although the Android operating system is linux, it is different from most
>
2017-12-11 14:58 GMT+01:00 Xavier de Gaye :
> The host running the buildbots must be able to run 6 (i.e. 3 x (version 3.x
> + maintenance version)) emulators simultaneously, so with an eight core cpu,
> that will be 6 cores running at 100%. The armv7 and arm64 buildbot may be
> set to run only dail
I'm asking for precise hardware specifications since Red Hat may be
able to provide one through the https://osci.io/ program.
Victor
2017-12-11 15:40 GMT+01:00 Victor Stinner :
> 2017-12-11 14:58 GMT+01:00 Xavier de Gaye :
>> The host running the buildbots must be able to r
2017-12-12 15:02 GMT+01:00 Antoine Pitrou :
> It sounds reasonable to me, as long as someone is monitoring their
> results (that would probably be you).
There is now the buildbot-status where failures are reported. Trust
me, I like making a lot of noise when something is broken :-)
FYI I'm trying
201 - 300 of 3215 matches
Mail list logo
