Hi, Nick and all core devs who are interested in this PEP.
I'm reviewing PEP 538 and I want to accept it in this month.
It will reduces much UnicodeError pains which server-side OPs facing.
Thank you Nick for working on this PEP.
If you have something worrying about this PEP, please post a commen
On Fri, May 5, 2017 at 1:25 AM, Antoine Pitrou wrote:
> On Thu, 4 May 2017 11:24:27 +0900
> INADA Naoki wrote:
>> Hi, Nick and all core devs who are interested in this PEP.
>>
>> I'm reviewing PEP 538 and I want to accept it in this month.
>> It will reduces m
an hide warning by setting
PYTHONUTF8=1 too.
On Fri, May 5, 2017 at 10:21 PM, INADA Naoki wrote:
> On Fri, May 5, 2017 at 1:25 AM, Antoine Pitrou wrote:
>> On Thu, 4 May 2017 11:24:27 +0900
>> INADA Naoki wrote:
>>> Hi, Nick and all core devs who are interested in this
>>> On platforms where they would have no effect (e.g. Mac OS X, iOS, Android,
>>> Windows) these preprocessor variables would always be undefined.
>>
>> Why ``--with[out]-c-locale-coercion`` have no effect on macOS, iOS and
>> Android?
>
> On these three, we know the system encoding is UTF-8, so
Hi, Nick.
I read again and I think PEP 538 is mostly ready for accepted,
without waiting PEP 540.
One remaining my concern is setting LANG.
> Setting LANG to C.UTF-8 ensures that even components that only check the LANG
> fallback for their locale settings will still use C.UTF-8 .
https://www.p
s and envvar option to disable it for people
who want to continue to use C locale explicitly.
Congrats, Nick!
On Sat, May 27, 2017 at 4:19 PM, Nick Coghlan wrote:
> On 24 May 2017 at 02:34, Nick Coghlan wrote:
>> On 23 May 2017 at 18:38, INADA Naoki wrote:
>>> Would you add e
Hi,
I'm interested in startup time too, not only execution time.
Here is very rough test:
with open('with_abc.py', 'w') as f:
print("import abc", file=f)
for i in range(1, 1001):
print(f"class A{i}(metaclass=abc.ABCMeta): pass", file=f)
with open('without_abc.py', 'w') as f:
Hello.
AFAIK, allocating arena doesn't eat real (physical) memory.
* On Windows, VirtualAlloc is used for arena. Real memory page is assigned
when the page is used first time.
* On Linux and some other *nix, anonymous mmap is used. Real page is
assigned when first touch, like Windows.
Aren
Hi,
As you said, I think PyObject_Malloc() is fast enough.
But PyObject_Free() is somewhat complex.
Actually, there are some freelists (e.g. tuple, dict, frame) and
they improve performance significantly.
My "global unified freelist" idea is unify them. The merit is:
* Unify _PyXxx_DebugMallo
> * On Linux, madvice(..., MADV_DONTNEED) can be used.
Recent Linux has MADV_FREE. It is faster than MADV_DONTNEED,
https://lwn.net/Articles/591214/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
If we use very large arena, or stop returning arena to system,
it can be problem.
Regards,
On Thu, Jun 1, 2017 at 6:05 PM, Siddhesh Poyarekar wrote:
> On Thursday 01 June 2017 01:53 PM, INADA Naoki wrote:
>> * On Linux, madvice(..., MADV_DONTNEED) can be used.
>
> madvise does not re
x86's hugepage is 2MB.
And some Linux enables "Transparent Huge Page" feature.
Maybe, 2MB arena size is better for TLB efficiency.
Especially, for servers having massive memory.
On Thu, Jun 1, 2017 at 4:38 PM, Larry Hastings wrote:
>
>
> When CPython's small block allocator was first merged in
I thought pymalloc is SLAB allocator.
What is the difference between SLAB and pymalloc allocator?
On Thu, Jun 1, 2017 at 6:20 PM, Victor Stinner wrote:
> 2017-06-01 10:40 GMT+02:00 Antoine Pitrou :
>> This is already exactly how PyObject_Malloc() works. (...)
>
> Oh ok, good to know...
>
>> IMHO
> I would be curious of another test: use pymalloc for objects larger
> than 512 bytes. For example, allocate up to 4 KB?
Since current pool size is 4KB and there is pool_header in pool,
we can't allocate 4KB block from pool.
And if support 1KB block, only 3KB of 4KB can be actually used.
I think
> 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
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
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.
>> -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
ll BytesIO.read directly instead of _Unframer.read.
Regards,
INADA Naoki
On Sun, Jul 9, 2017 at 11:08 PM, Bhavishya wrote:
> Hello,
>
> 1).I was going through the code of python pickle to search any optimization
> possibility.But the only thing that I found very alarming was again the
>
I said about pure Python implementation (unpickle_pure_python),
because mail title is "Pure pickle bechmark".
INADA Naoki
On Mon, Jul 10, 2017 at 8:36 AM, Victor Stinner
wrote:
> Wait. Are we talking about the C accelerator or the pure Python
> implementation of pickle on Pyth
use of realloc(),
* resulting in more predictable performance.
Regards,
INADA Naoki
On Sat, Jul 15, 2017 at 4:01 PM, Max Moroz wrote:
> What would be the disadvantage of implementing collections.deque as a
> circular array (rather than a doubly linked list of blocks)? My naive
> thi
+ eval pattern in CPython.
But namedtuple is very widely used.
It's loved enough to get optimized for not only CPython.
So I prefer Jelle's approach to adding code cache machinery in this case.
Regards,
INADA Naoki
___
Python-Dev
Hi, Ivan.
First of all, Yes, please do it!
On Thu, Jul 20, 2017 at 8:24 PM, Ivan Levkivskyi wrote:
> I agree the start-up time is important. There is something that is related.
> ABCMeta is currently implemented in Python.
> This makes it slow, creation of an ABC is 2x slower than creation of a
On Fri, Jul 21, 2017 at 4:12 PM, David Mertz wrote:
> How implausible is it to write out the actual memory image of a loaded
> Python process? I.e. on a specific machine, OS, Python version, etc? This
> can only be overhead initially, of course, but on subsequent runs it's just
> one memory map, w
unsafe tp_dealloc.
Even "extending and embedding" document missed untracking.
Regards,
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.o
nalize is used widely (like `__del__`), I
agree with you.
But I'm not good English writer.
Contribution is welcome.
Regards,
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
FYI, there is issue report for it.
http://psf.upfronthosting.co.za/roundup/meta/issue463
INADA Naoki
On Fri, Sep 1, 2017 at 9:57 PM, Victor Stinner wrote:
> Hi,
>
> When I go to http://bugs.python.org/ Firefox warns me that the form on
> the left to login (user, password) sends d
b is 'http://bugs.python.org/' instead of
'https://bugs.python.org/'
INADA Naoki
On Fri, Sep 1, 2017 at 10:29 PM, Antoine Pitrou wrote:
> On Fri, 1 Sep 2017 22:15:29 +0900
> INADA Naoki wrote:
>> FYI, there is issue report for it.
>> http://psf.upfronthosting.co.za
dDict, _Link,
_OrderedDictKeyViews, _OrderedDictItemsView, and _OrderedDictValuesView).
Three of them inheriting from ABC. So it makes importing collections
bit slower.
## Cons
* All Python 3.7 implementations should provide _collections.OrderedDict
PyPy has it already. But I don't know abo
request yet.
(Can I create without issue, as trivial patch?)
I'm very busy these days, maybe until December.
But I hope this report helps people working on optimizing startup time.
Regards,
INADA Naoki
___
Python-Dev mailing list
Python-Dev@pyt
optimize, but also better behavior.
Pure Python version is not thread safe even for `od[k] = v`.
It's very difficult to write thread safe complex container in Pure Python.
Regards,
INADA Naoki
___
Python-Dev mailing list
Python-Dev@py
On Tue, Sep 5, 2017 at 8:48 PM, Serhiy Storchaka wrote:
> 05.09.17 11:38, INADA Naoki пише:
>>
>> ## Cons
>>
>> * All Python 3.7 implementations should provide _collections.OrderedDict
>>PyPy has it already. But I don't know about micropython.
>
>
First of all, I saw enough -1 so I gave up about removing.
Following reply is just a technical topic.
On Wed, Sep 6, 2017 at 2:13 AM, Eric Snow wrote:
[snip]
>
> Like Antoine, I consider the pure Python implementation to be
> valuable. Furthermore, the pure Python implementation is the
> refere
Congrats!
INADA Naoki
On Wed, Sep 6, 2017 at 10:10 AM, Mariatta Wijaya
wrote:
> Hi,
>
> The cherry picker bot has just been deployed to CPython repo, codenamed
> miss-islington.
>
> miss-islington made the very first backport PR for CPython and became a
> first time GitH
uding stdlib)?
Currently, dict ordering is implementation detail of CPython and PyPy.
We don't recommend to rely on the behavior.
Like that, should we say "atomic & threadsafe __setitem__ for simple
key is implementation detail of CPython and PyPy. We recommend
>>
>> I haven't created pull request yet.
>> (Can I create without issue, as trivial patch?)
>
>
> Trivial, no-issue PRs are meant for things like typo fixes that need no
> discussion or record.
>
> Moving imports in violation of the PEP 8 rule, "Imports are always put at
> the top of the file, jus
>> With this profile, I tried optimize `python -c 'import asyncio'`, logging
>> and http.client.
>>
>>
>> https://gist.github.com/methane/1ab97181e74a33592314c7619bf34233#file-0-optimize-import-patch
>>
> This patch moves a few imports inside functions. I wonder whether that kind
> of change actual
>> This patch moves a few imports inside functions. I wonder whether that kind
>> of change actually helps with real applications—doesn't any real application
>> end up importing the socket module anyway at some point?
>
> I don't know if this particular change is worthwhile, but one place
> where
other example is GAE/Python.
Anyway, I think researching import tree of popular library is good startline
about optimizing startup time.
For example, modules like ast and tokenize are imported often than I thought.
Jinja2 is one of libraries I often use. I'm checking other libraries
like reques
OK, I stop worring about thread safety and other implementation
detail behavior on edge cases.
Thanks,
INADA Naoki
On Wed, Sep 6, 2017 at 7:40 PM, Paul Moore wrote:
> On 6 September 2017 at 11:09, Antoine Pitrou wrote:
>> On Wed, 6 Sep 2017 11:26:52 +0900
>> INA
can be solved "PEP 549: Instance
Properties (aka: module properties)")
* Optimize enum creation.
* Faster namedtuple (There is pull request already)
* Faster ABC
* Breaking large import tree in stdlib. (PEP 549 may help this too)
Regards,
INADA Naoki
_
ocstring, we can not
use -OO if a time set of module depends on docstring or assertion.
So I think we need some mechanizm to disable optimization like
dropping assertions, docstrings, and annotations per module.
--
Inada Naoki
___
Python-Dev mailin
, `42`,
`"foo"` are not rewrote).
This tool can ease transition from PEP 563 to 649, and solve
performance issues too.
PEP 649 can have the performance as PEP 563 if all annotations are constants.
--
Inada Naoki
___
Python-Dev mail
Memory consumption is cost on process lifetime.
And longer GC time is every time when full-GC is happened.
So performance is problem for both of short lifecycle applications
like CLI tools and long lifecycle applications like Web app.
Regards,
--
Inada Naoki
__
ave the same (zero) cost. Yay!
But if SQLAlchemy starts using annotations, *all applications* using
SQLAlchemy will be impacted in the future.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-l
period and I am
helping people to use new APIs. (*)
* e.g. https://github.com/jamesturk/cjellyfish/pull/12
So I don't want to increase the minimum required deprecation period.
But I agree that a longer deprecation period is good when keeping
deprecation st
the
default behavior"?
Then, we do not need to decide "PEP 563 or 649".
We can focus on whether we can replace "stock semantics + opt-in PEP
563" with PEP 649 or not.
Regards,
--
Inada Naoki
___
Python-Dev mailing list --
4bytes. And NULL can not store pointer. So upper bound of refcnt is
2**30-1.
So we have two free bits in the refcnt.
On 64bit machine, we have at least four free bits as same reason.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev
-github-keeps-getting-better-for-open-source-maintainers/
--
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
or triage members but not merged yet.
> I know "drive by approvals" are annoying but I think it is unfortunately part
> of open source projects.
>
Sorry, but I don't think so.
--
Inada Naoki
___
Python-Dev mailin
change the pull request status. So I can ignore them.
I just explain "what the motivation approve without review repeatedly".
I don't watch the cpython repository so I am not suffered from spammy
approvals. So I have no vote for it. I just mention to an option we
have.
Regards,
--
In
ecause user may want to use own libmysqlclient, and I don't
want to maintain binary linking OpenSSL.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https:/
tate(module);
Py_IDENTIFIER_CLEAR(state->foo);
}
```
--
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-de
.python.org/archives/list/python-dev@python.org/message/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email t
are not interned.
I think deepfreeze should stop using statically allocated strings for
interned strings too.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mai
gt; things out seem reasonable to me.
>
I like it. I want to use anonymous union. It makes complex structure
like PyDictKeysObject simple a little.
I confirmed that XLC supports it.
https://www.ibm.com/docs/en/xl-c-and-cpp-aix/13.1.3?topic=types-structures-unions#strct__anonstruct
Regards,
-
e reasonable limitations.
https://en.cppreference.com/w/cpp/language/union
XL C/C++ also support it. So we can use it if we decided to use it.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an e
rtal to be shared between subinterpreters.
If the interned dict is belonging to interpreter, should we register
immortalized string to all interpreters?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
ide some data, or drop the CoW issue from this PEP until
it is proved?
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/py
all immortal objects during runtime finalization,
> we must keep track of them.
>
I don't think we need to clean up all immortal objects.
Of course, we should care immortal by default objects.
But for user-marked immortal objects, it's very difficult to guarantee
__del__ or weakr
On Wed, Feb 23, 2022 at 10:12 AM Eric Snow wrote:
>
> Thanks for the feedback. I've responded inline below.
>
> -eric
>
> On Sat, Feb 19, 2022 at 8:50 PM Inada Naoki wrote:
> > I hope per-interpreter GIL success at some point, and I know this is
> > needed for
chnique don't guarantee same benefit. Like gc.freeze() is
needed before immortalize to avoid CoW, some other tricks may be
needed too.
New article is welcome, but I want sample application we can run,
profile, and measure the benefits.
Regards,
--
Inada Naoki
age archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LA6U263OUVJ2RBFHFYNFXZ2QSCZHVVUW/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
python.org/issue47000
https://github.com/python/cpython/pull/32068
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.
Hi, all.
I wrote a new PEP last month.
I'm sorry that I forgot to announce it here.
The pep is here:
https://peps.python.org/pep-0686/
Discussions:
* https://discuss.python.org/t/14737 (current thread)
* https://discuss.python.org/t/14435 (previous thread)
--
Inada
xplicitly UTF-8:
>
> # no surprise, always decode file content from UTF-8
> json_file = open(filename, encoding="utf-8")
>
> --
>
> I will not comment PEP 686 here. It's being discussed on Discourse:
>
> * https://discuss.python.org/t/14435
> * https:/
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
-initializers -Wstrict-prototypes
-Werror=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
___
see any problem with 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/l
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
on.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/list/python-dev@python.org/message/EMFDKQ57JVWUZ6TPZM5VTFW7EUKVYAOY/
> Code of Conduct: http:/
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
. So 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 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 m
;> 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 u
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 proposal
eue need 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.pyt
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
//mail.python.org/mailman3/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-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/IBK2T4YR5JARRJOCNHRLI3JN2Z737JXH/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Na
nd (list|tuple).__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 li
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
___
P
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/
.
Note that we 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-d
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.
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 em
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
>>
would be a better approach.
> Since 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
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,
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 Cytho
ckport the
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 e
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`` in
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
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
rcase, _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.
--
I
tead 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
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
>
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
e
So 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 archiv
ping 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_ToL
401 - 500 of 538 matches
Mail list logo
