[Python-Dev] Stable ABI question.

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

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

by compiler. 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.or

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

Unicode 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

[Python-Dev] Re: Stable ABI question.

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

[Python-Dev] Re: Recent PEP-8 change

RFC is very inclusive 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-de

[Python-Dev] Re: Stable ABI question.

s subinterpreters 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] Re: Stable ABI question.

Eval_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 -

[Python-Dev] Tips: Searching deprecated API usage.

es. 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/archives/li

[Python-Dev] PEP 624: Remove Py_UNICODE encoder APIs

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`` encod

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

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."

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

e, when > 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@pytho

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

said removing the wchar_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-Dev] Re: I plan to accept PEP 623 "Remove wstr from Unicode" next week

PIs). >> >> 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.

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

n.org/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 _

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

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 tim

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

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 a

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

ode blocks, but it is not 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-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

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 cur

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

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

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

have 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://mai

Re: [Python-Dev] GSoC: Replace MS Windows Console with Unicode UI

Hi. I'm Japanese and non-ascii charactor user. (cp932) We have to use "IME" to input non-ascii charactor in Windows. When "> chcp 65001" in cmd.exe, we cannot use IME on cmd.exe. So setting codepage to 65001 make output universal but make input ascii-only. Sit!!! I hope PyQtShell

Re: [Python-Dev] GSoC: Replace MS Windows Console with Unicode UI

Hi. >> We have to use "IME" to input non-ascii charactor in Windows. >> When "> chcp 65001" in cmd.exe, we cannot use IME on cmd.exe. >> >> So setting codepage to 65001 make output universal but make input ascii-only. >> Sit!!! > > Is there a code page that still allows IME input, but supports all

[Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

I found this hg's issue. http://mercurial.selenic.com/bts/msg8375 I think below fix is not enabled on Mac OS X. http://svn.python.org/view/python/trunk/Include/pyport.h?view=diff&pathrev=43219&r1=36792&r2=36793 I can't confirm it because I am not Mac OS X user. Can anyone confirm it? -- Naoki I

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

> Do you have a testcase that shows what the problem is? > > Ronald >>> s = '\xa0' >>> assert s.strip() == s >>> import locale >>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8') 'en_US.UTF-8' >>> assert s.strip() == s Second assert failed on Snow Leopard. -- Naoki INADA __

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

> Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail. OK. `s = '\xa0'` should be `s = b'\xa0'`. Should I file a bug? -- Naoki INADA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] transitioning from % to {} formatting

What about using string prefix 'f'? f"{foo} and {bar}" % something == "{foo} and {bar}.format(something) s = f"{foo}" t = "%(bar)s" s + t # raises Exception Transition plan: n: Just add F prefix. And adding "format_string" in future. n+1: deprecate __mod__() without 'F'. n+2: libraries

Re: [Python-Dev] transitioning from % to {} formatting

> -1 That requires keeping formatting information around in every string > instance. Adding new "format_string" class avoids it. unicode("foo") <=> u"foo" format_string("foo") <=> f"foo" This way's pros: * Many libraries can use one transition way. * Transition stage syncs to Python version. "l

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

I filed as issue7072. On Tue, Oct 6, 2009 at 10:49 PM, Ronald Oussoren wrote: > > On 3 Oct, 2009, at 1:40, INADA Naoki wrote: > >>> Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail. >> >> OK. >> `s = '\xa0'` should be `s = b&#x

Re: [Python-Dev] logging package vs unicode

x - Content Management, Batch Processing & Python Consulting >            - http://www.simplistix.co.uk > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscr

[Python-Dev] What is PyBuffer_SizeFromFormat?

PyBuffer_SizeFromFormat is documented and defined in abstract.h. But I can't find an implementation of the function. Do I overlook anything? -- INADA Naoki  ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/lis

[Python-Dev] What's L2R status?

for more information. >>> C=0 >>> def x(): ... global C ... C += 1 ... return C ... >>> {x(): x(), x(): x()} {2: 1, 4: 3} -- INADA Naoki  ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailm

Re: [Python-Dev] What's L2R status?

Sorry. There is a issue already. http://bugs.python.org/issue11205 On Sun, Feb 20, 2011 at 1:19 AM, INADA Naoki wrote: > Ref: http://bugs.python.org/issue448679 > > Has this bug fixed already? > This bug seems not be fixed for Python 2.6 and Python 3.2rc3. > > Python 3.2rc3 (r3

Re: [Python-Dev] counterintuitive behavior (bug?) in Counter with +=

ommit/de6e93094499e4d81b8e3b15fc66b6b9252945af > [2] http://hg.python.org/cpython/file/tip/Lib/collections/__init__.py#l399 > > > -- > Lars Buitinck > Scientific programmer, ILPS > University of Amsterdam > _______ > Python-Dev mailing list > Python-Dev@python.org > h

Re: [Python-Dev] Packaging and binary distributions

at happens with > binary eggs. > > Unix/MacOS users who care will need to propose something themselves. > > Does anyone have any comments? > > Paul. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > -- INADA Naoki  ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

people are coming > up with so many templating systems (templating isn't "obvious"). > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > U

Re: [Python-Dev] Playing with a new theme for the docs

> Georg > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com -- INADA N

[Python-Dev] What is the "sequence"? ([issue16728] collections.abc.Sequence shoud provide __subclasshook__

em__ but default iterator uses only __getitem__. This difference is ugly. -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

<    1   2   3   4   5   6