Hi, all.
I updated the PEP 597 yesterday.
Please review it to move it forward.
PEP: https://www.python.org/dev/peps/pep-0597/
Previous thread: https://discuss.python.org/t/3880
Main difference from the previous version:
* Added new warning category; EncodingWarning
* Added dedicated option to
Hi, Lemburg.
I want to send the PEP to SC.
I think I wrote all your points in the PEP. Would you review it?
Regards,
On Tue, Aug 4, 2020 at 5:04 PM Inada Naoki wrote:
>
> On Tue, Aug 4, 2020 at 3:31 PM M.-A. Lemburg wrote:
> >
> > Hi Inada-san,
> >
> > thanks for
On Tue, Jan 19, 2021 at 8:54 AM Larry Hastings wrote:
>
> On 1/18/21 3:42 PM, Inada Naoki wrote:
>
> Many type hinting use cases don't need type objects in runtime.
> So I think PEP 563 is better for type hinting user experience.
>
> You mean, in situations where the user d
ing use cases don't need type objects in runtime.
So I think PEP 563 is better for type hinting user experience.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...
This PEP doesn't cover about what happened when __co_annotation__()
failed (e.g. NameError).
Forward reference is a major reason, but not a only reason for using
string annotation. There are two other reasons:
* Avoid importing heavy module.
* Avoid circular imports.
In these cases, this
On Wed, Jan 13, 2021 at 1:47 AM Larry Hastings wrote:
>
> On 1/11/21 5:33 PM, Inada Naoki wrote:
>
> Note that PEP 563 semantics allows more efficient implementation.
> Annotation is just a single constant tuple, not a dict.
> We already have the efficient implementati
> Performance
> ---
>
> Performance with this PEP should be favorable. In general,
> resources are only consumed on demand—"you only pay for what you use".
>
Nice!
> There are three scenarios to consider:
>
> * the runtime cost when annotations aren't defined,
> * the runtime cost when
ants to use completely different internal
representation, it must not be a unicode object at all.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.p
On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote:
>
> On Mon, 28 Dec 2020 11:07:46 +0900
> Inada Naoki wrote:
> >
> > Additionally, if we introduce the customizable lazy str object, it's
> > very easy to release GIL during basic Unicode operations. Many t
bjects (including subclass) but any objects implementing some
protocol.
We already have __index__ for integers and buffer protocol for
byts-like objects. That is examples of the policy.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@pyth
ode_READY() and make it no-op
macro since Python 3.12.
But I don't know how many third-parties use it properly, because
legacy Unicode objects are very rare already.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.o
ssue title.
* E.g. "needs compiler experts", "xml", "http", "mail", etc...
It will help to find PRs I can help in my spare time.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.
s feature to lower
> maintenance burden.
Which warning helped you? str(bytes)? bytes == str? or bytes == int?
I am not much concerned about removing str(bytes) warning anytime soon.
Only bytes== warning is significant maintenance burden.
Reg
eptions.html#built-in-exceptions
This is mentioned from the reviced tutorial, python-dev thread, and b.p.o issue.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
and the tutorial is the only
> place
> where some concepts are presented in a discursive way ... even if not
> "beginner friendly".
>
You know, exception chaining is described well in other place so it was removed.
I promise that I don't remove something in the tutoria
And deleting `__cause__` is not solery for "didactic" reason, nor
"loosing something precious."
As written in the b.p.o. issue, mention only `__cause__` "lose some precious".
We need to describe `__context__` and `__suppress_context__` too.
But all of them are documented
On the other hand, I want to remove confusion by removing mention to
`__cause__`.
Because I don't think `__context__` and `__cause__` is important for new users.
See https://github.com/python/cpython/pull/23162 for my proposal.
Regards,
--
Inada Naoki
__
nicode case, because
this is the most annoying part.
3.11: Stop emitting BytesWarning in core and stdlib.
4.0: Remove `-b` option, `sys.flags.bytes_warning`, and `BytesWarning`.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
ithub.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Modules/_functoolsmodule.c#L802
https://github.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Objects/codeobject.c#L724
(maybe more, but I'm not sure)
Regards,
--
Inada Naoki
__
no-op. Bytes warning never emits.
3.12: Remove the -b option.
BytesWarning will be deprecated in the document, but not to be removed.
Users who want to use the -b option during 2->3 conversion need to use
Python ~3.10 for a while.
Regards,
--
Inada Na
a lot of time.
Bests,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.pyt
Hi, Lemburg.
Thank you for organizing the EuroPython 2020.
I enjoyed watching some sessions from home.
I think current PEP 624 covers all your points and ready for Steering
Council discussion.
Would you like to review the PEP before it?
Regards,
On Thu, Jul 9, 2020 at 8:19 AM Inada Naoki
On Wed, Jul 22, 2020 at 10:53 PM Antoine Pitrou wrote:
>
>
> Le 22/07/2020 à 15:48, Inada Naoki a écrit :
> > On Wed, Jul 22, 2020 at 8:51 PM Antoine Pitrou wrote:
> >>
> >>>
> >>> I don't think all attempts are failed. Note that current
worth enough. And
it is not related to execution speed.
On the other hand, if we can not remove lnotab, it is still
considerable to avoid having two lnotabs in -O mode.
Memory overhead of lnotab is not negligible.
Regards,
--
Inada Naoki
___
Python-De
On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou wrote:
>
> >
> > But if we merge two equal code blocks, we can not produce precise line
> > numbers, can we?
> > Is this inconsistent microoptimization that real optimization harder?
> > This optimization must be prohibited in future Python?
>
> All
On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon wrote:
>
> On 18/07/2020 9:20 am, Inada Naoki wrote:
> > It seems great improvement, but I am worrying about performance.
> >
> > Adding more attributes to the code object will increase memory usage
> > and importing
/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/BMX32UARJFY3PZZYKRANS6RCMR2XBVVM/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
___
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https:
t* member is motivation for PEP 624.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archi
gt; these are ways to continue exposing the functionality using other
> data types.
I hope the "Replace Py_UNICODE* with Py_UCS4* " section describe this.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To uns
revious lookup". If you have (say) "case
> socket.AddressFamily.AF_INET", does it cache "socket",
> "socket.AddressFamily", or both?
>
I meant "It is implementation detail" and "User must not rely on side effects
of attribute access."
up "Sides" only once, instead of two?
* Can VM cache the value of "Sides.SPAM" and "Sides.EGGS" for next execution?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
et): https://www.python.org/dev/peps/pep-0624/
---
PEP: 624
Title: Remove Py_UNICODE encoder APIs
Author: Inada Naoki
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 06-Jul-2020
Python-Version: 3.11
Abstract
This PEP proposes to remove deprecated ``Py_UNICODE`` en
/notes/blob/master/2020/wchar-cache/download_sdist.py
Note that this script doesn't download packages without sdist (e.g.
only universal wheel).
It is because I have searched Python/C API.
We can reduce the pain of the removal by fixing most of top 4000 packages.
Regards,
--
Inada Naoki
PyEval_ReleaseLock is not
deprecated yet in C.
https://github.com/python/cpython/blob/master/Include/ceval.h#L132
Maybe, we can uncomment Py_DEPRECATE in 3.10, and remove it from
header file in 3.12.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- pyt
preters and uses/used
> daemon threads.
>
I think they use only PyEval_ReleaseLock(). Do they use
PyEval_AcquireLock() too?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev
ive for the engineers in the world.
I don't think I can write such clear English without help. But having
such a goal is inclusive
for non native English readers.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
Thanks. I will do it.
On Wed, Jul 1, 2020 at 5:50 PM Serhiy Storchaka wrote:
>
> 01.07.20 04:35, Inada Naoki пише:
> > Hi, folks.
> >
> > I found PyEval_AcquireLock and PyEval_ReleaseLock are deprecated since
> > Python 3.2.
> > But the same time, sta
de object *and* char* buffer for UTF-8.
On the other hand, PyUnicode_AsUTF8AndSize can just expose internal
data when it is plain ASCII. Since ASCII string is very common, this
is effective
optimization.
Regards,
--
Inada Naoki
___
Python-Dev mailing l
ompiler.
The commit changed PyType_HasFeature to call regular function
PyType_GetFlags always.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mai
not remove them until Python 4.0. Am I right?
I will add comment like this.
/* This is a part of stable ABI. Do not remove until Python 4.0 */
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python
functions to use full not
> simple casemaps per Unicode's recommendation". IMHO the replacement
> function is to call lower() and method() of a Python str object.
>
We have private functions; _PyUnicode_ToTitleFull, _PyUnicode_ToLowerFull,
PyUnicode_AsEncodedString can not replace them.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
On Mon, Jun 29, 2020 at 12:17 AM Inada Naoki wrote:
>
>
> More aggressive idea: override current PyUnicode_EncodeXXX() apis.
> Change from `Py_UNICODE *object` to `PyObject *unicode`.
>
This is a list of PyUnicode_Encode usage in top4000 packages.
https://gist.git
On Sun, Jun 28, 2020 at 11:24 PM Inada Naoki wrote:
>
>
> So how about making them public, instead of undeprecate Py_UNICODE* encode
> APIs?
>
> 1. Add PyUnicode_AsXXXBytes public APIs in Python 3.10.
>Current private APIs can become macro (e.g. #define
>
of undeprecate Py_UNICODE* encode APIs?
1. Add PyUnicode_AsXXXBytes public APIs in Python 3.10.
Current private APIs can become macro (e.g. #define
_PyUnicode_AsAsciiString PyUnicode_AsAsciiBytes),
or deprecated static inline function.
2. Remove Py_UNICODE* encode APIs
, _PyUnicode_ToUppercase
They are not deprecated by PEP 393, but bpo-12736.
They are documented as deprecated, but don't have ``Py_DEPRECATED``.
Plan: Add Py_DEPRECATED in 3.9, and remove them in 3.11.
Note: _PyUnicode_ToTitlecase has Py_DEPRECATED. It can be removed in 3.10.
--
Inada Naoki
On Tue, Jun 23, 2020 at 6:31 PM Victor Stinner wrote:
>
> Le mar. 23 juin 2020 à 04:02, Inada Naoki a écrit :
> > Legacy unicode representation is using wstr so legacy unicode support
> > is removed with wstr.
> > PyUnicode_READY() will be no-op when wstr is removed. W
On Tue, Jun 23, 2020 at 6:58 AM Victor Stinner wrote:
>
> Hi INADA-san,
>
> First of all, thanks for writing down a PEP!
>
> Le jeu. 18 juin 2020 à 11:42, Inada Naoki a écrit :
> > To support legacy Unicode object created by
> > ``PyUnicode_FromUnicode(NULL, le
PEP:
Title: Remove wstr from Unicode
Author: Inada Naoki
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 18-Jun-2020
Python-Version: TBD
Abstract
PEP 393 deprecated some unicode APIs, and introduced ``wchar_t *wstr``,
and ``Py_ssize_t wstr_length
runtime DeprecationWarning to 3.9, because we need to fix Argument
Clinic too. (Serhiy's pull request fix the Argument Clinic.)
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-
On Wed, Jun 17, 2020 at 4:16 AM Steve Dower wrote:
>
> On 16Jun2020 1641, Inada Naoki wrote:
> > * This change doesn't affect to pure Python packages.
> > * Most of the rest uses Cython. Since I already report an issue to Cython,
> >regenerating with new C
On Tue, Jun 16, 2020 at 9:30 PM Victor Stinner wrote:
>
> Le mar. 16 juin 2020 à 10:42, Inada Naoki a écrit :
> > Hmm, Is there any chance to add DeprecationWarning in Python 3.9?
>
> In my experience, more and more projects are running their test suite
> with -Werror,
this discussion is on-going for something like 5 years in
> multiple bugs.python.org issues and email threads, maybe it would help
> to have a short PEP describing issues of the deprecated functions,
> explain the plan to migrate to the new functions, and give a sche
On Sat, Jun 13, 2020 at 8:20 PM Inada Naoki wrote:
>
> 2020年6月13日(土) 20:12 Kyle Stanley :
>>
>> > Additionally, raise DeprecationWarning runtime when these APIs are used.
>>
>> So, just to clarify, current usage of these 7 unicode APIs does not emit any
>>
2020年6月13日(土) 20:12 Kyle Stanley :
> > Additionally, raise DeprecationWarning runtime when these APIs are used.
>
> So, just to clarify, current usage of these 7 unicode APIs does not emit
> any warnings and would only start doing so in 3.10?
>
They have been deprecated in C already. Compiler
On Fri, Jun 12, 2020 at 5:32 PM Inada Naoki wrote:
>
>
> My proposal is, schedule the removal on Python 3.11. But we will postpone
> the removal if we can not remove its usage until it.
>
Additionally, raise DeprecationWarning runtime when these APIs are used.
can remove wchar_t cache while keeping it working.
Anyway, this is an idea for mitigation. If all of maintained packages fixes it
before Python 3.11, mitigation is not needed.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
T
n length>0.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/
change for per interpreter GIL, but not
for sub interpreters.
https://github.com/python/cpython/pull/20645
Should we commit this change to the master branch?
Or should we create another branch for such changes?
Regards,
--
Inada Naoki
___
Python
uple).__contains__ uses it too.
It is very important to compare recursive sequences.
>>> x = []
>>> x.append(x)
>>> y = [x]
>>> z = [x]
>>> y == z
True
--
Inada Naoki
___
Python-Dev mailing list -- pyth
.@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/IBK2T4YR5JARRJOCNHRLI3JN2Z737JXH/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
_
3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AAZQBWD6PHC4PVNCCPX4A2745SS7B3LS/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
___
Python
On Sat, Dec 21, 2019 at 3:17 AM Tim Peters wrote:
>
> [Wes Turner ]
> >> How slow and space-inefficient would it be to just implement the set
> >> methods
> >> on top of dict?
>
> [Inada Naoki ]
> > Speed: Dict doesn't cache the position of the firs
eed to have?
I want O(1) D.popleft(). (The name is borrowed from deque. popfirst()
would be better maybe).
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.o
On Mon, Dec 16, 2019 at 6:25 PM Inada Naoki wrote:
>
> +1 for 1 and 2.
>
If we find it broke some software, we can step back to regular
deprecation workflow.
Python 3.9 is still far from beta yet. That's why I'm +1 on these proposals.
--
In
;> x.decode(errors="strict")
'おはよう'
So allowing `bytes(o, errors="replace")` instead of making encoding
mandatory also makes sense to me.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscr
On Mon, Dec 16, 2019 at 1:33 PM Guido van Rossum wrote:
>
> Actually, for dicts the implementation came first.
>
I had tried to implement the Ordered Set. Here is the implementation.
https://github.com/methane/cpython/pull/23
Regards,
___
Python-Dev
there we decided to keep things
> insecure because otherwise code would break, even "wrong" code.
It is not a good example because we didn't release Python 2.8.
Hash randomization might be enabled by default if we released Python 2.8.
Regards,
--
Inada Naoki
_
On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder wrote:
>
> On 12/3/19 8:13 PM, Inada Naoki wrote:
> > I think it is too early to determine when to remove it.
> > Even only talking about it causes blaming war.
>
> Has anyone yet given a reason to remove it?
Note that &quo
; To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/EMFDKQ57JVWUZ6TPZM5VTFW7EUKVYAOY/
> Code of Conduct: http://python.or
On Wed, Oct 30, 2019 at 11:55 PM Oz Tiram wrote:
>
> Hi Steve,
>
> Thanks for your reply. While dataclass provide a cleaner API than DictRow
> (you can access `row.id` instead of `row["id"]`).
> However, dataclass still use the built in `__dict__` instead of `__slots__`.
>
> This means that the
h Homebrew
> optimizing for a particular user's installation. I see that MacPorts,
> another distributor of Python on macOS, provides a non-default variant that
> uses --enable-optimizations.
>
> https://github.com/macports/macports-ports/blob/master/lang/python37/Portfile
>
r=implicit-function-declaration
-I/Users/sysadmin/build/v3.8.0/Include/internal'
>>> sysconfig.get_config_var('PY_LDFLAGS_NODIST')
''
>>> sysconfig.get_config_var('PY_LDFLAGS')
'-arch x86_64 -g'
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python
/45337
Are these options used for official macOS binaries?
Is there official information about the build step of official binaries?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pyth
Thank you for confining it!
Currently, Python defines PY_FORMAT_SIZE_T as:
#ifndef PY_FORMAT_SIZE_T
# if SIZEOF_SIZE_T == SIZEOF_INT && !defined(__APPLE__)
# define PY_FORMAT_SIZE_T ""
# elif SIZEOF_SIZE_T == SIZEOF_LONG
# define PY_FORMAT_SIZE_T "l"
# elif defined(MS_WINDOWS)
# define
d a few hours to read some PDFs and searching
but I can not
find any official document about snprintf(3).
I feel it's impossible to support such platforms...
Except AIX, I believe all platforms supports size_t and %zd because
it's very basic
C99 feature.
Regards,
--
Inada Naoki
_
nd-wprintf-functions?view=vs-2015
"%zd" is standard C99 feature. Can we assume it is portable for now?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
n items view does.
-1. What is the motivation of this?
In this case, I don't think "I found missing parts so I want to
implement it for consistency"
is not enough reason to implement it.
I want a real-world application which requires it.
Without a strong use case, I think the d
On Tue, Jul 16, 2019 at 11:07 PM Jeroen Demeyer wrote:
>
> On 2019-07-16 15:33, Inada Naoki wrote:
> >> We currently have a deprecation policy saying that functions deprecated
> >> in version N cannot be removed before version N+2. That's a reasonable
> >> po
WIW, there is PendingDeprecationWarning for something discouraged
but not deprecated, and will be deprecated in the future.
But I prefer simple deprecation.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send a
> Mean +- std dev: [python-master] 199 ms +- 1 ms -> [python] 182 ms +-
> 4 ms: 1.10x faster (-9%)
...
> I will try to split pymalloc_alloc and pymalloc_free to smaller functions.
I did it and pymalloc is now as fast as mimalloc.
$ ./python bm_spectral_norm.py --compare-to=./python-master
On Wed, Jul 10, 2019 at 5:18 PM Neil Schemenauer wrote:
>
> On 2019-07-09, Inada Naoki wrote:
> > PyObject_Malloc inlines pymalloc_alloc, and PyObject_Free inlines
> > pymalloc_free.
> > But compiler doesn't know which is the hot part in pymalloc_alloc and
> >
On Tue, Jul 9, 2019 at 5:29 PM Inada Naoki wrote:
>
> On Tue, Jul 9, 2019 at 9:46 AM Tim Peters wrote:
> >
> >> I was more intrigued by your first (speed) comparison:
> >
> > > - spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)
> >
blame? Perhaps mimalloc's
> larger (16x) pools and arenas let it stay in its fastest paths more
> often? I don't know why, but it would be interesting to find out :-)
Totally agree. I'll investigate this next.
Regards,
--
Inada Naoki
On Thu, Jul 4, 2019 at 11:32 PM Inada Naoki wrote:
>
> On Thu, Jul 4, 2019 at 8:09 PM Antoine Pitrou wrote:
> >
> > Ah, interesting. Were you able to measure the memory footprint as well?
> >
>
> Hmm, it is not good. mimalloc uses MADV_FREE so it may affect to s
MB
...
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives
20.8 kB -> 66.5 MB +- 21.1 kB: 1.07x slower (+7%)
- python_startup: 7946.6 kB +- 20.4 kB -> 8210.2 kB +- 16.6 kB: 1.03x
slower (+3%)
- python_startup_no_site: 7409.0 kB +- 18.3 kB -> 7574.6 kB +- 21.8
kB: 1.02x slower (+2%)
```
--
Inada Naoki
_
On Tue, Jun 25, 2019 at 5:49 AM Antoine Pitrou wrote:
>
>
> For the record, there's another contender in the allocator
> competition now:
> https://github.com/microsoft/mimalloc/
>
> Regards
>
> Antoine.
It's a very strong competitor!
$ ./python -m pyperf compare_to pymalloc.json mimalloc.json
e instead of a binary wheel
or Cython source code.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.p
OK. I start optimizing PyUnicode_GetString() already.
It was 2x slower than _PyUnicode_FromASCII.
But it can be only 1.5x slower than _PyUnicode_FromASCII.
And as a bonus, `b"foo".decode()` become 10% faster too.
--
Inada Naoki
___
hon.
So I wanted to discuss we really need to support non-ASCII before that.
But it seems I was late already.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.p
On Fri, Jun 21, 2019 at 1:28 AM Victor Stinner wrote:
>
> Le jeu. 20 juin 2019 à 11:15, Inada Naoki a écrit :
> > Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
>
> How would a developer detect a mistake (non-ASCII) character? Does
> _PyUnicode_FromASCII() rai
all usage in CPython uses ASCII only, and _Py_Identifier is still private.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.pyt
_PyUnicode_FromId to use _PyUnicode_FromASCII?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
eople who want to use huge page may have a problem to solve by huge page.
But I don't have it.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.
On Mon, Jun 17, 2019 at 5:18 PM Antoine Pitrou wrote:
>
> On Mon, 17 Jun 2019 11:15:29 +0900
> Inada Naoki wrote:
> >
> > Increasing pool size is one obvious way to fix these problems.
> > I think 16KiB pool size and 2MiB (huge page size of x86) arena size is
>
4 42 256 1.5625
400 40 384 2.34375
416 39 160 0.9765625
432 37 400 2.44140625
448 36 256 1.5625
464 35 144 0.87890625
480 34 64 0.390625
496 32 512 3.125
512 31 512 3.125
```
Another way to fix these problems is shrinking SMALL_REQUEST_THRESHOLD
to 256 and believe malloc works well fo
t; regex_effbot; scimark_lu; scimark_monte_carlo; scimark_sor;
> sqlalchemy_declarative; sqlite_synth; sympy_integrate; sympy_sum;
> sympy_str; telco; unpack_sequence; unpickle; xml_etree_iterparse
> ___
> Python-Dev mailing list -
private/ (with PyAPI_FUNC) in 3.9,
for users like Cython.
If you want to make it public in 3.9, please create new thread.
Let's discuss about how it is useful, and current name and signature
are good enough to make it public.
Regards,
--
Inada Naoki
___
101 - 200 of 535 matches
Mail list logo
