[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-06-15 Thread Serhiy Storchaka
12.06.20 11:32, Inada Naoki пише: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are documented as "

[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-06-15 Thread Kyle Stanley
> I'm sorry, I was wrong. Py_DEPRECATED(3.3) is commented out for some APIs. So Python 3.8 doesn't show warning for them. Ah, no problem. Thanks for checking up on that. > I still think 2 years are enough to removal. Hmm, okay. At the least though, it does mean we have to be a bit more vigilant

[Python-Dev] Re: Cycles in the __context__ chain

2020-06-15 Thread Dennis Sweeney
Worth noting is that there is an existing loop-breaking mechanism, but only for the newest exception being raised. In particular, option (4) is actually the current behavior if the the most recent exception participates in a cycle: Python 3.9.0b1 >>> A, B, C, D, E = map(Exception, "ABCDE"

[Python-Dev] Re: Cycles in the __context__ chain

2020-06-15 Thread Chris Jerdonek
On Sun, Jun 14, 2020 at 9:19 AM Serhiy Storchaka wrote: > It is possible to create a loop by setting the __context__ attribute of > the raised exception, either explicitly, or implicitly, using "raise ... > from ...". I think we should separate the questions of what to do when (1) setting the c

[Python-Dev] Re: Removal of _Py_ForgetReference from public header in 3.9 issue

2020-06-15 Thread Petr Viktorin
On 2020-06-14 22:10, cpyt...@nicwatson.org wrote: Please excuse if this is the wrong mailing list. I couldn't find one for module maintainers. This is relevant to capi-...@python.org; let's continue here. I maintain an open source Python module in C. I'm trying to verify for the first time

[Python-Dev] Re: [capi-sig] Re: Removal of _Py_ForgetReference from public header in 3.9 issue

2020-06-15 Thread M.-A. Lemburg
On 15.06.2020 11:02, Petr Viktorin wrote: > On 2020-06-14 22:10, cpyt...@nicwatson.org wrote: >> I maintain an open source Python module in C. I'm trying to verify for >> the first time that the module still works with cpython 3.9. This >> module does *not* use the "limited" C API. >> >> In buildin

[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-06-15 Thread Mark Shannon
Hi Serhiy, On 15/06/2020 8:22 am, Serhiy Storchaka wrote: 12.06.20 11:32, Inada Naoki пише: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine)

[Python-Dev] Improving inspect capabilities for classes

2020-06-15 Thread Thomas Viehmann
Hello, thank you for making Python and the neat inspect module. I would love to hear your opinion on the following aspect of inspect that I believe might be worth improving: Consider the following program saved in a file (say hello.py): import inspect def hello(): print("Hello World") p

[Python-Dev] Re: How to specify optional support of arguments

2020-06-15 Thread Guido van Rossum
IMO it is up to the offending module to provide an API for advertising which variant of those functions is accepted. This seems out of scope for inspect. On Sun, Jun 14, 2020 at 23:16 Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 15.06.2020 8:45, Serhiy Storchaka wrote: > > 1

[Python-Dev] Re: When can we remove wchar_t* cache from string?

2020-06-15 Thread Victor Stinner
Hi INADA-san, IMO Python 3.11 is too early because we don't emit a DeprecationWarning on every single deprecation function. 1) Emit a DeprecationWarning at runtime (ex: Python 3.10) 2) Wait two Python releases: see https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 3) Remove

[Python-Dev] Re: How to specify optional support of arguments

2020-06-15 Thread Emily Bowman
Isn't it more Pythonic to simply call the function and an alternative path to handle the exception, anyway? Half of os needs to be tested for NotImplementedError or OSError if it's going to run anywhere outside the development environment anyway, otherwise you're stuck with only the most basic func

[Python-Dev] REPL output bug

2020-06-15 Thread Rob Cliffe via Python-Dev
If I run the following program (using Python 3.8.3 on a Windows 10 laptop): import sys, time for i in range(1,11):     sys.stdout.write('\r%d' % i)     time.sleep(1) As intended, it displays '1', replacing it at 1-second intervals with '2', '3' ... '10'. Now run the same code inside the REPL:

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Stefan Ring
> Now run the same code inside the REPL: > > Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32 > bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys, time > >>> for i in range(1,11): > ... sys.stdout.write('\r%

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Richard Damon
On 6/12/20 4:01 AM, Rob Cliffe via Python-Dev wrote: > If I run the following program (using Python 3.8.3 on a Windows 10 > laptop): > > import sys, time > for i in range(1,11): >     sys.stdout.write('\r%d' % i) >     time.sleep(1) > > As intended, it displays '1', replacing it at 1-second interva

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Ivan Pozdeev via Python-Dev
On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote: If I run the following program (using Python 3.8.3 on a Windows 10 laptop): import sys, time for i in range(1,11):     sys.stdout.write('\r%d' % i)     time.sleep(1) As intended, it displays '1', replacing it at 1-second intervals with '2',

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Joseph Jenne via Python-Dev
On 2020-06-15 15:26, Ivan Pozdeev via Python-Dev wrote: On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote: If I run the following program (using Python 3.8.3 on a Windows 10 laptop): import sys, time for i in range(1,11):     sys.stdout.write('\r%d' % i)     time.sleep(1) As intended, it

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Steven D'Aprano
On Fri, Jun 12, 2020 at 09:01:33AM +0100, Rob Cliffe via Python-Dev wrote: > If I run the following program (using Python 3.8.3 on a Windows 10 laptop): > > import sys, time > for i in range(1,11): >     sys.stdout.write('\r%d' % i) In Python 2, the 'write()` method returns None, which is suppres

[Python-Dev] Re: Proposed release schedule for 3.5.9

2020-06-15 Thread Larry Hastings
Oh, good point!  I forgot about that and was, uh, looking in the wrong place.  Yes, the next version will be 3.5.10. //arry/ On 6/14/20 2:30 PM, John Thorvald Wodder II wrote: 3.5.9 was already released back in November. Yes, it's (almost) the same code as 3.5.8, but its version number (

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Jonathan Goble
On Mon, Jun 15, 2020 at 8:31 PM Steven D'Aprano wrote: > On Fri, Jun 12, 2020 at 09:01:33AM +0100, Rob Cliffe via Python-Dev wrote: > > It appears that the requested characters are output, *followed by* the > > number of characters output > > (which is the value returned by sys.stdout.write) and

[Python-Dev] Re: Improving inspect capabilities for classes

2020-06-15 Thread Guido van Rossum
On Mon, Jun 15, 2020 at 7:22 AM Thomas Viehmann < tv.python-dev.python@beamnet.de> wrote: > Hello, > > thank you for making Python and the neat inspect module. > > I would love to hear your opinion on the following aspect of inspect > that I believe might be worth improving: > > Consider the f

[Python-Dev] Re: REPL output bug

2020-06-15 Thread Greg Ewing
On 16/06/20 12:20 pm, Steven D'Aprano wrote: The whole point of the REPL is to evaluate an expression and have the result printed. (That's the P in REPL :-) Still, it's a bit surprising that it prints results of expressions within a compound statement, not just at the top level. -- Greg __