[issue39513] NameError: name 'open' is not defined

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Symptoms as when try to log very late at shutdown stage, when the content of 
the builtin module is restored to its original value which does not include 
open imported from io.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39479] [RFE] Add math.lcm() function: Least Common Multiple

[Vedran Čačić]

Vedran Čačić  added the comment:

Tim: Considering that congruence is _defined_ as x=y(mod m) :<=> m|y-x, it's 
really not so surprising. :-)

Steven: It seems that we completely agree about inclusion of 
is_probabilistic_prime in stdlib. And we agree that it should be called isprime 
(or is_prime if Raymond names it;). About the bikeshedding, see Tim's comment. 
:-P

About absolutely correct algorithms: first, what exactly is your claim? If it's 
"I can write an algorithm in pure Python that can for every number of 397 
digits mathematically exactly determine whether it is prime in under 6 
seconds", I'd very much like to see that algorithm. (I guess it must be 
publicly available, since we're speaking about inclusion in Python stdlib.) I 
really don't have much expertise in number theory that I can be convinced it 
doesn't exist, but I very much doubt it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39479] [RFE] Add math.lcm() function: Least Common Multiple

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Fri, Jan 31, 2020 at 12:15:37PM +, Vedran Čačić wrote:
> 
> Vedran Čačić  added the comment:
> 
> is_prime that's always correct is probably not the right thing to go into 
> math. Besides, now we have isqrt, it's just
> 
> n>1 and n&1 and all(n%d for d in range(3,isqrt(n)+1,2))
> 
> -- yes, it's damn slow, but so is everything else you want to be absolutely 
> correct. :-]

Lots of things are fast and still absolutely correct.

And I think that you probably are underestimating just how slow trial 
division is for testing primes. I can imagine you've probably tested it 
on "large numbers" like a trillion-trillion (1e18) and thought that's 
acceptably fast. Try it on numbers like this:

P = int('29674495668685510550154174642905332730771991'
'79985304335099507553127683875317177019959423'
'8596428121188033664754218345562493168782883')
Q = P*(313*(P-1)+1)*(353*(P-1)+1)

Q is a 397 digit Carmichael Number. Its smallest factor is P, which has 
131 digits. If your computer is fast enough to perform a thousand 
trillion (1e15) divisions per second, your trial division will take more 
than 3e107 years to complete. That's 10 million trillion trillion 
trillion trillion trillion trillion trillion trillion trillion times 
longer than the universe has existed.

In a practical sense, your algorithm is never going to terminate. The 
sun will burn out and die first.

Upgrading your CPU is not going to help.

My old and slow PC can prove that Q is a composite number, using pure 
Python, in less than six seconds. And I'm sure that a better programmer 
than me would be able to shave off some of that time.

> is_probable_prime is another matter, but there is an enormous amount 
> of bikeshedding about the API of that one.

What is there to bikeshed about the API?

The API should be a function that takes a single integer, and returns 
False if that number is certainly composite[1] otherwise True.

I will argue that any other details -- including whether it is 
probabilistic or not -- are *quality of implementation* issues and not 
part of the API.

For the same reason, the name should be just "is_prime" (or "isprime") 
and not disturb naive users by calling it "probably prime".

Experts will read the documentation and/or the source code, and everyone 
else can happily ignore the microscopic[2] chance of a false positive 
with really huge numbers. (Sometimes ignorance really is bliss.)

We can argue on technical grounds just what the implementation should 
be, but that's not part of the API, and the implementation could change:

- Miller-Rabin, or Baillie–PSW, or AKS, or something else;
- whether probabilistic or deterministic;
- what error rate (if any) we are willing to accept;

etc.

If we choose the fast, simple Miller-Rabin test, with just 30 random 
iterations the error rate is less than approximately one in a trillion 
trillion. If we tested a million numbers ever second, it would take over 
18,000 years (on average) to find one false positive.

If that isn't good enough, increase the number of iterations to 50, in 
which case you would expect one false positive every 20,000 trillion 
years.

In comparison, it is estimated that cosmic rays cause memory bit 
flips as often one error per 4GB of RAM per day. This probabilistic 
algorithm is more reliable than your determinstic computer.

https://blogs.oracle.com/linux/attack-of-the-cosmic-rays-v2

https://www.johndcook.com/blog/2019/05/20/cosmic-rays-flipping-bits/

I don't have much time for worries about Miller-Rabin being 
"probabilistic". When I was young and naive I worried about it a lot, 
and maybe that was a legitimate worry for a naive Miller-Rabin 
implementation that did, say, five iterations (probability of a false 
positive about 0.1%).

But with 30 or 50 rounds, I am confident that nobody will ever 
experience such a false positive, not if they spend their entire 
lifetime doing nothing but calling `is_prime`.

Let's be real: if the banks are willing to trust the transfer of 
billions of dollars to probabilistic primality testing, why are we 
worring about this?

(By the way: for smallish numbers, under 2**64, no more than twelve 
rounds of Miller-Rabin are sufficient to deterministically decide 
whether a number is prime or not. Likewise for Baillie–PSW, which is 
also completely deterministic for numbers up to 2**64.)

[1] For ease of discussion, we'll count zero and one as composite.

[2] More like nanoscopic or picoscopic.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39528] add "

[SilentGhost]

Change by SilentGhost :


--
nosy:  -bup
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38506] Launcher for Windows (py.exe) may rank Python 3.xx (in the future) after 3.x

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +17684
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18307

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39513] NameError: name 'open' is not defined

[Vinay Sajip]

Vinay Sajip  added the comment:

Please attach a small script which allows reproduction of this issue - 
otherwise, it's unlikely we'll be able to make much progress, and I'll probably 
close it in a week or so if you haven't been able to do this. Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39526] print(text1.get(1.2,1.5))

[mlwtc]

mlwtc  added the comment:

Look at line 5:print(text1.get(1.0,1.30))
I think the result should be "abcdefghijklmnopqrstuvwxyz1234"

print(text1.get(1.0,1.20))
I think the result should be "abcdefghijklmnopqrst"

print(text1.get(1.0,1.10))
I think the result should be "abcdefghij"

 Others are correct,So I don't know why these results are not my expected.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39528] add "

[Dan Snider]

Change by Dan Snider :


--
nosy: bup
priority: normal
severity: normal
status: open
title: add "

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39525] math.remainder() give wrong answer on large integer

[Tim Peters]

Tim Peters  added the comment:

Arguments to `remainder()` are converted to floats, and the returned value is 
also a float.  These specific arguments convert to the same float:

>>> a = 12345678901234567890
>>> b = 12345678901234567891
>>> float(a) == float(b)
True

And the float they convert _to_ retains only the 53 most-significant bits of 
the inputs:

>>> int(float(b))
12345678901234567168
>>> c = _
>>> c.bit_length()
64
>>> bin(c)
'0b101010110101010010101001100011001110101100011000'

Note that the last 11 bits are zeroes, and 64 - 11 = 53.

So this is all doing what it's intended to do, and won't be changed.

I'm leaving this open, though, in case someone thinks the docs should be 
clarified.  But the same things apply to _many_ functions in the `math` module: 
 unless the docs specifically say they work with integer arguments, integer 
arguments are converted to float.

Oops!  Someone else already closed this while I was typing.  That's fine by me 
too ;-)

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39526] print(text1.get(1.2,1.5))

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Is there a bug here?

How about if you tell us what behaviour you expected, why you expected it, and 
what you got instead, then we can tell you if your expectation was correct and 
whether or not there is a bug.

You have seven results printed. I have no idea which ones you think are wrong.

--
components: +Tkinter -Build
nosy: +steven.daprano
type: compile error -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14074] argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple

[hai shi]

Change by hai shi :


--
versions: +Python 3.9 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14074] argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple

[hai shi]

hai shi  added the comment:

> Given that tuple metavars currently doesn't work, there is no backward 
> compatibility issue.  What is being proposed is to give more friendly error 
> messages.

Got it, thanks.

> Paul suggested that it may be a better plan to just disallow tuple metavars 
> and to give a better error message as the OP suggested.  That makes sense to 
> me.

+1

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39525] math.remainder() give wrong answer on large integer

[Steven D'Aprano]

Steven D'Aprano  added the comment:

math.remainder performs *floating point* remainder. That means it has to 
convert the arguments to floats first, and there is no float capable of 
representing either of those two numbers exactly:

py> '%f' % float(12345678901234567890)
'12345678901234567168.00'
py> '%f' % float(12345678901234567891)
'12345678901234567168.00'

That's just the way floats work. They don't have infinite precision, so 
sometimes they have rounding error.

If you want exact integer remainder, use the `%` operator:

py> 12345678901234567890 % 3
0
py> 12345678901234567891 % 3
1

See the tutorial and the FAQs

https://docs.python.org/3/tutorial/floatingpoint.html

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39527] Update doc of argparse.rst

[hai shi]

Change by hai shi :


--
keywords: +patch
pull_requests: +17683
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18306

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39527] Update doc of argparse.rst

[hai shi]

New submission from hai shi :

1. examples don't need import argparse much times(IMHO, it should be a default 
behavior);
2. argparse have no doctest, it's not a good behavior;

--
assignee: docs@python
components: Documentation
messages: 361213
nosy: docs@python, mdk, rhettinger, shihai1991
priority: normal
severity: normal
status: open
title: Update doc of argparse.rst
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39526] print(text1.get(1.2,1.5))

[mlwtc]

New submission from mlwtc :

>>> from tkinter import *
>>> root = Tk()
>>> text1 = Text(root,width=30,height=3)
>>> text1.insert(INSERT,'abcdefghijklmnopqrstuvwxyz123456789123456789')
>>> print(text1.get(1.0,1.30))
abc
>>> print(text1.get(1.0,1.31))
abcdefghijklmnopqrstuvwxyz12345
>>> print(text1.get(1.0,1.20))
ab
>>> print(text1.get(1.0,1.21))
abcdefghijklmnopqrstu
>>> print(text1.get(1.0,1.10))
a
>>> print(text1.get(1.0,1.11))
abcdefghijk
>>> print(text1.get(1.0,1.9))
abcdefghi
  

   Is there a bug here?

--
components: Build
messages: 361212
nosy: mlwtc
priority: normal
severity: normal
status: open
title: print(text1.get(1.2,1.5))
type: compile error
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39525] math.remainder() give wrong answer on large integer

[David Hwang]

New submission from David Hwang :

These two numbers are off by 1, and so should give different answer to
>>> math.remainder(12345678901234567890,3)
1.0
>>> math.remainder(12345678901234567891,3)
1.0

--
components: Library (Lib)
messages: 361211
nosy: David Hwang
priority: normal
severity: normal
status: open
title: math.remainder() give wrong answer on large integer
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39479] [RFE] Add math.lcm() function: Least Common Multiple

[Tim Peters]

Tim Peters  added the comment:

I'd have to hear back from Raymond more on what he had in mind - I may well 
have been reading far too much in the specific name he suggested.

Don't much care about API, etc - pick something reasonable and go with it.  I'm 
not overly ;-) concerned with being "newbie friendly".  If someone is in a 
context where they need to use probabilistic solutions, there is no substitute 
for them learning something non-trivial about them.  The usual API for a 
Miller-Rabin tester supports passing in the number of bases to try, and it's as 
clear as anything of this kind _can_ be then that the probability of getting 
back True when the argument is actually composite is no higher than 1 over 4 to 
the power of the number of bases tried.  Which is also the way they'll find it 
explained in every reference.  It's doing nobody a real favor to make up our 
own explanations for a novel UI ;-)

BTW, purely by coincidence, I faced a small puzzle today, as part of a larger 
problem:

Given that 25 is congruent to 55 mod 10, and also mod 15, what's the largest 
modulus we can be certain of that the congruence still holds?  IOW, given

x = y (mod A), and
x = y (mod B)

what's the largest C such that we can be certain

x = y (mod C)

too?  And the answer is C = lcm(A, B) (which is 30 in the example).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38988] Killing asyncio subprocesses on timeout?

[Caleb Hattingh]

Caleb Hattingh  added the comment:

@dontbugme This is a very old problem with threads and sub-processes.  In the 
general case (cross-platform, etc) it is difficult to kill threads and 
sub-processes from the outside. The traditional solution is to somehow send a 
message to the thread or subprocess to tell it to finish up. Then, you have to 
write the code running the thread or subprocess to notice such a message, and 
then shut itself down. With threads, the usual solution is to pass `None` on a 
queue, and have the thread pull data off that queue. When it receives a `None` 
it knows that it's time to shut down, and the thread terminates itself. This 
model can also be used with the multiprocessing module because there is a Queue 
instance provided there that works across the inter-process boundary.  
Unfortunately, we don't have that feature in the asyncio subprocess machinery 
yet. For subprocesses, there are three options available:

1) Send a "shutdown" sentinal via STDIN (asyncio.subprocess.Process.communicate)
2) Send a process signal (via asyncio.subprocess.Process.send_signal)
3) Pass messages between main process and child process via socket connections

My experience has been that (3) is the most practical, esp. in a cross-platform 
sense. The added benefit of (3) is that this also works, unchanged, if the 
"worker" process is running on a different machine. There are probably things 
we can do to make (3) easier. Not sure.

I don't know if my comment helps, but I feel your pain. You are correct that 
`wait_for` is not an alternative to `timeout` because there is no actual 
cancellation that happen.

--
nosy: +cjrh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35108] inspect.getmembers passes exceptions from object's properties through

[Richard Bruskiewich]

Richard Bruskiewich  added the comment:

This "bug" is buzzing around my project head right now, interfering with the 
operation of the Python Fire CLI library when it attempts to interrogate the 
Python Pandas DataFrame using the inspect.getmembers() call. See 
https://github.com/pandas-dev/pandas/issues/31474 and 
https://github.com/pandas-dev/pandas/pull/31549.

I have code that uses Fire and Pandas, but have to "dumb it down" to use Pandas 
0.24.3 rather than the latest 0.25.1 which raises a "NotImplementedError" which 
leaks out of the getmembers() call.  The Pandas people are passing the buck to 
you folks in the Python community.

This is terribly frustrating for we minions in the real work trying to 
implementing real working software systems leveraging all these wonderful 
libraries (and the Python language).

When is this "bug" going to be fixed? Help!

--
nosy: +richardbruskiewich

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39524] Escape sequences in doc string of ast._pad_whitespace

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39483] Proposial add loop parametr to run in asyncio

[Caleb Hattingh]

Caleb Hattingh  added the comment:

Hmm, my recent comment looks rude but I didn't intend it to be that way. What I 
mean is: there are many, many more users of asyncio.run than there are of 
teleton, so any change made to asyncio.run is going to affect more people than 
the other way round. So before we regard this as something that will be 
generally useful (run() taking a loop parameter), it will be faster to check if 
the 3rd party library provides a way to work with the std library.  FWIW I have 
an alternative run() implementation, with the PYPI package "aiorun" in which I 
do allow a loop parameter to be passed in. So far, it's only caused headaches 
for me as the maintainer :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39483] Proposial add loop parametr to run in asyncio

[Caleb Hattingh]

Caleb Hattingh  added the comment:

@heckad You should instead ask the maintainers of teleton how to use their 
library with asyncio.run, not the other way round.

--
nosy: +cjrh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39524] Escape sequences in doc string of ast._pad_whitespace

[mpheath]

mpheath  added the comment:

Correction: Python 3.8.0 and 3.8.1 with 3.8/Lib/ast.py:277

Line 227 is invalid and 277 is correct and forgot to add 3.8 prefix. Sorry.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39524] Escape sequences in doc string of ast._pad_whitespace

[mpheath]

mpheath  added the comment:

Correction: Python 3.8.0 and 3.8.1 with Lib/ast.py:277

Line 227 is invalid and 277 is correct.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39524] Escape sequences in doc string of ast._pad_whitespace

[mpheath]

New submission from mpheath :

In the ast module, a function named _pad_whitespace has a doc string with 
escape sequences of \f and \t.

The current doc string from Lib/ast.py:305 is:

"""Replace all chars except '\f\t' in a line with spaces."""

Example of doc string output in a REPL:

Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> import inspect
>>> inspect.getdoc(ast._pad_whitespace)
"Replace all chars except '\x0c ' in a line with spaces."
>>>

The \x0c is the formfeed and the ' ' (5 spaces) was the tab.

It is my understanding that the output should be:

"Replace all chars except '\f\t' in a line with spaces."

I would expect the source to be:

"""Replace all chars except '\\f\\t' in a line with spaces."""

or perhaps a raw string:

r"""Replace all chars except '\f\t' in a line with spaces."""

The current Lib/ast.py:305 is Python 3.9.0 alpha 3 though the issue is also in 
Python 3.8.0 and 3.8.1 with 3.8/Lib/ast.py:227 .
Python 3.7.4 3.7/Lib/ast.py does not have the function _pad_whitespace as it 
appears major code changes occurred in the ast module with Python 3.8.0.

--
messages: 361203
nosy: mpheath
priority: normal
severity: normal
status: open
title: Escape sequences in doc string of ast._pad_whitespace
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18819] tarfile fills devmajor and devminor fields even for non-devices

[William Chargin]

William Chargin  added the comment:

My pleasure. Is there anything else that you need from me to close this
out? It looks like the PR is approved and in an “awaiting merge” state,
but I don’t have access to merge it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39294] zipfile.ZipInfo objects contain invalid 'extra' fields.

[Daniel Hillier]

Daniel Hillier  added the comment:

This looks to be expected behaviour for the zip64 extension in the zip spec 
(for handling large files or large archives).

Section 4.4.1.4 of the zip spec outlines when the zip64 extra fields are used 
(https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT). In short, when 
the file offset header (number of bytes to the start of the file in the 
archive) exceeds the size allotted in the header in the original spec 
(0x or just under 2Gb).

Let me know if what you're observing is unrelated to this.

--
nosy: +dhillier

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39523] Unnecessary variable assignment and initial loop check in pysqlite_cursor_executescript

[Alex Henrie]

Change by Alex Henrie :


--
keywords: +patch
pull_requests: +17682
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18305

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39523] Unnecessary variable assignment and initial loop check in pysqlite_cursor_executescript

[Alex Henrie]

New submission from Alex Henrie :

pysqlite_cursor_executescript currently has the following while loop:

/* execute statement, and ignore results of SELECT statements */
rc = SQLITE_ROW;
while (rc == SQLITE_ROW) {
rc = pysqlite_step(statement, self->connection);
if (PyErr_Occurred()) {
(void)sqlite3_finalize(statement);
goto error;
}
}

This can and should be rewritten as a do-while loop to avoid having to 
initialize rc to SQLITE_ROW and then check its value knowing that the value 
check will succeed.

--
components: Library (Lib)
messages: 361200
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Unnecessary variable assignment and initial loop check in 
pysqlite_cursor_executescript
type: performance
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39010] ProactorEventLoop raises unhandled ConnectionResetError

[Caleb Hattingh]

Change by Caleb Hattingh :


--
nosy: +cjrh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39522] AST Unparser with unicode kinded constants

[Batuhan]

New submission from Batuhan :

>>> from __future__ import annotations
>>> import ast
>>> x: u"a" = 3
>>> __annotations__["x"]
"'a'"
>>> ast.dump(ast.parse(__annotations__["x"])) == ast.dump(ast.parse('u"a"'))
False

I guess before touching constant part, we should wait for GH-17426 (afterward I 
can prepare a patch)

--
components: Interpreter Core
messages: 361199
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: AST Unparser with unicode kinded constants
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39521] reversed(mylist) much slower on Python 3.8 32-bit for Windows

[Raymond Hettinger]

Raymond Hettinger  added the comment:

The code for listiter_next() and listreviter_next() is almost the same. 

The main difference that the code for reversed saves the index to Py_ssize_t 
variable.  Maybe that causes a 32-bit to 64-bit conversion and back.  The 
change was made on 30 March 2016 in fbb1c5ee068d209e33f6e15ecb4821d5d8b107fa

Another possible cause is that this is just a random build outcome due to PGO 
or incidental branch mis-prediction from aliasing (as described in 
https://stackoverflow.com/a/17906589/1001643 ).

On the python.org mac 64-bit build, I'm not seeing any difference, so this is 
unique to the Windows 32-bit build.

$ python3.7 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(iter(a))"
100 loops, best of 11: 3.08 msec per loop
$ python3.7 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(reversed(a))"
100 loops, best of 11: 3.04 msec per loop
$ python3.8 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(iter(a))"
100 loops, best of 11: 3.07 msec per loop
$ python3.8 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(reversed(a))"
100 loops, best of 11: 3.01 msec per loop

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39521] reversed(mylist) much slower on Python 3.8 32-bit for Windows

[Stefan Pochmann]

Stefan Pochmann  added the comment:

Oh right. The times are correct, I just summarized wrongly there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39521] reversed(mylist) much slower on Python 3.8 32-bit for Windows

[Stefan Pochmann]

Change by Stefan Pochmann :


--
title: reversed(mylist) much slower on Python 3.8.1 32-bit for Windows -> 
reversed(mylist) much slower on Python 3.8 32-bit for Windows

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39521] reversed(mylist) much slower on Python 3.8.1 32-bit for Windows

[SilentGhost]

SilentGhost  added the comment:

Your 3.8.0 numbers are similar to 3.8.1

--
components: +Interpreter Core -Build
nosy: +SilentGhost, serhiy.storchaka, vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39521] reversed(mylist) much slower on Python 3.8.1 32-bit for Windows

[Stefan Pochmann]

New submission from Stefan Pochmann :

Somehow `reversed` became much slower than `iter` on lists:

List with 1,000 elements:

> python -m timeit -s "a = list(range(1000))" "list(iter(a))"
5 loops, best of 5: 5.73 usec per loop

> python -m timeit -s "a = list(range(1000))" "list(reversed(a))"
2 loops, best of 5: 14.2 usec per loop

List with 1,000,000 elements:

> python -m timeit -s "a = list(range(250)) * 4000" "list(iter(a))"
50 loops, best of 5: 7.08 msec per loop

> python -m timeit -s "a = list(range(250)) * 4000" "list(reversed(a))"
20 loops, best of 5: 15.5 msec per loop

On another machine I tried ten different Python versions and found out it's 
only version 3.8.1 and only the 32-bit version:

32-bit  64-bit
CPython iter   reversed iter   reversed
 3.5.4  19.8 19.9   22.4 22.7
 3.6.8  19.8 19.9   22.3 22.6
 3.7.6  19.9 19.9   22.3 22.5
 3.8.1  19.8 24.9   22.4 22.6

Another time with 3.8.0 instead of 3.8.1:

32-bit  64-bit
CPython iter   reversed iter   reversed
 3.5.4  19.5 19.6   21.9 22.2
 3.6.8  19.5 19.7   21.8 22.1
 3.7.6  19.5 19.6   21.7 22.0
 3.8.0  19.4 24.5   21.7 22.1

I used the "Stable Releases" "executable installer"s from here:
https://www.python.org/downloads/windows/

More details here: https://stackoverflow.com/q/60005302/12671057

--
components: Build
messages: 361195
nosy: Stefan Pochmann
priority: normal
severity: normal
status: open
title: reversed(mylist) much slower on Python 3.8.1 32-bit for Windows
type: performance
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39519] Can't upgrade pip version 19.3.1 to 20.0.2 on Python 3.7.4

[SilentGhost]

SilentGhost  added the comment:

`pip install --help` provides full list of options, the upgrade option is -U or 
--upgrade.

--
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: security -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39520] AST Unparser can't unparse ext slices correctly

[Batuhan]

Change by Batuhan :


--
keywords: +patch
pull_requests: +17681
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18304

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39520] AST Unparser can't unparse ext slices correctly

[Batuhan]

New submission from Batuhan :

(this issue has already a PR for ast.unparse)

>>> from __future__ import annotations
>>> import ast
>>> x: Tuple[1:2,] = 3
>>> __annotations__["x"]
'Tuple[1:2]'
>>> ast.dump(ast.parse("Tuple[1:2,]"))
"Module(body=[Expr(value=Subscript(value=Name(id='Tuple', ctx=Load()), 
slice=ExtSlice(dims=[Slice(lower=Constant(value=1, kind=None), 
upper=Constant(value=2, kind=None), step=None)]), ctx=Load()))], 
type_ignores=[])"

>>> ast.dump(ast.parse("Tuple[1:2]"))
"Module(body=[Expr(value=Subscript(value=Name(id='Tuple', ctx=Load()), 
slice=Slice(lower=Constant(value=1, kind=None), upper=Constant(value=2, 
kind=None), step=None), ctx=Load()))], type_ignores=[])"

--
components: Interpreter Core
messages: 361193
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: AST Unparser can't unparse ext slices correctly
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Berker Peksag]

Berker Peksag  added the comment:


New changeset 78c7183f470b60a39ac2dd0ad1a94d49d1e0b062 by Alex Henrie in branch 
'master':
bpo-39496: Remove redundant checks from _sqlite/cursor.c (GH-18270)
https://github.com/python/cpython/commit/78c7183f470b60a39ac2dd0ad1a94d49d1e0b062


--
nosy: +berker.peksag

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Berker Peksag]

Change by Berker Peksag :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39514] http://sphinx.pocoo.org/

[Berker Peksag]

Berker Peksag  added the comment:

https://github.com/python/docsbuild-scripts/pull/83

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39514] http://sphinx.pocoo.org/

[Mariatta]

Mariatta  added the comment:

I tested locally, if I build the docs using python-docs-theme 2020.1, the link 
is fixed.

I'm reopening this ticket.

I think it is a matter of making sure docs.p.o is using the right version of 
python-docs-theme. (v 2020.1)

--
resolution: out of date -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39519] Can't upgrade pip version 19.3.1 to 20.0.2 on Python 3.7.4

[brasko]

New submission from brasko :

Hi when I want to upgrade pip version I get:

Usage:
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip 
install [options]  [package-index-options] ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip 
install [options] -r  [package-index-options] ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip 
install [options] [-e]  ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip 
install [options] [-e]  ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip 
install [options]  ...

no such option: -u

--
components: Windows
messages: 361189
nosy: brasko, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't upgrade pip version 19.3.1 to 20.0.2 on Python 3.7.4
type: security
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39391] Pydoc: add option to remove run-specific ids (addresses)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Sorry, I was thinking of something else when I closed this.  What you want is a 
new -x option, for some 'x'.  The following would help, especially as there is 
no one who specifically maintains pydoc.

a) a specific proposal or set of proposals as to what letter to use for the 
option and what the result should be.

b) a currently failing test case (based on the above).

c. a patch for test.test_pydoc adding the test, preferably self-contained (no 
added file)  -- or does any current test already involve an 'at 0x' 
output?

d. a patch for  pydoc.py making the test pass.

--
resolution: third party -> 
stage: resolved -> test needed
status: closed -> open
title: Run-dependent Pydoc output for functions default parameters -> Pydoc: 
add option to remove run-specific ids (addresses)
type: behavior -> enhancement
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39516] ++ does not throw a SyntaxError

[Marco Sulla]

Marco Sulla  added the comment:

> `++` isn't special

Indeed the problem is that no error or warning is raised if two operators are 
consecutive, without a space between. All the cases you listed are terribly 
unreadable and hardly intelligible. 

Anyway I do not agree `++` is not special:

> you should know that this example is a syntax error because you are missing 
> the right hand operand, not because `++` has no meaning

But you should know that in a *lot* of other popular languages, `++` and `--` 
are unary operators, so it's particularly surprisingly to see that they *seems* 
to work in Python, even if they *seems* to be a binary operator.

This is completely confusing and messy. Frankly, I'm not a PEP 8 orthodox at 
all. I think that you can write `a+b`. It's not elegant, it's a bit less 
readable that `a + b`, but it's not the end of the world. 

But you should *not* be allowed to write `a+-b` without at least a warning, 
because `+-` seems a binary operator. And you should not be able to write `a+ 
-b` too, with the interpreter that acts like Ponzio Pilato, because what's 
this? Is it an unary `+` or an unary `-`? 
We know the unary is the `-`, `a+` has no sense. but for someone that does not 
know Python, __it's not readable__. So, IMHO, the interpreter should at least 
raise a warning if the syntax is not: 
`a + -b`
for any combination of binary and unary operators.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39518] Dark theme property of useragent should be supported for docs.python.org

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks, closing it as third party issue.

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed
title: Dark theme -> Dark theme property of useragent should be supported for 
docs.python.org

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14074] argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I am not sure disallowing tuple metavars would break backup 
> compatibility or not~

Given that tuple metavars currently doesn't work, there is no backward 
compatibility issue.  What is being proposed is to give more friendly error 
messages.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39518] Dark theme

[Vitaly Zdanevich]

Vitaly Zdanevich  added the comment:

Added bug report to their repo 
https://github.com/python/python-docs-theme/issues/43

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39517] runpy calls open_code with Path object

[Tomas Ravinskas]

Tomas Ravinskas  added the comment:

Can't see anything about this in the docs, I just noticed that it breaks shiv 
after upgrade.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39515] pathlib won't strip "\n" in path

[Eryk Sun]

Change by Eryk Sun :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39517] runpy calls open_code with Path object

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39517] runpy calls open_code with Path object

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Is there documentation in runpy where it's stated that path objects are 
accepted for the function? If not this seems to be an enhancement.

--
nosy: +ncoghlan, xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39515] pathlib won't strip "\n" in path

[Eryk Sun]

Eryk Sun  added the comment:

A Windows path reserves the following characters:

* null, as the string terminator
* slash and backslash, as path separators
* colon as the second character in the first component of
  a non-UNC path, since it's a drive path

Additionally, a normalized path reserves trailing dots and spaces on names, 
since they get stripped from the final component (e.g. "C:\Temp\spam. . ." -> 
"C:\Temp\spam"). WindowsPath could automatically strip trailing dots and space 
from normalized paths. This would need to exclude extended paths that begin 
with the "\\?\" prefix.

Otherwise the set of reserved characters is a function of device and filesystem 
namespaces, regardless of the recommendations in "Naming Files, Paths, and 
Namespaces" [1], which are meant to constrain applications to what is generally 
allowed. I would prefer for WindowsPath to remain generic enough to support all 
device and filesystem namespaces. 

For example, the VirtualBox shared-folder filesystem (a mini-redirector to the 
host system) allows colon, pipe, and control characters in file and directory 
names:

>>> control = '\a\b\t\n\v\f\r'
>>> special = ':|'
>>> dirname = f'//vboxsvr/work/nametest/{control}{special}'
>>> os.makedirs(dirname, exist_ok=True)
>>> os.listdir('//vboxsvr/work/nametest')[0]
'\x07\x08\t\n\x0b\x0c\r:|'

Like most filesystems, it reserves the 5 wildcard characters in base filenames, 
which includes '*', '?', '<' (DOS_STAR), '>' (DOS_QM), and '"' (DOS_DOT). A 
filesystem that fails to reserve these wildcard characters cannot properly 
support WINAPI FindFirstFile[Ex]. The only filesystem I can think of that 
allows wildcard characters in base names is the named-pipe filesystem. NPFS 
actually allows any character in a pipe name -- even slash and backslash since 
it only supports a single directory, the root directory "//./PIPE/".

That said, a path may specify a stream name instead of a base filename. As is 
documented in [1], and NTFS stream name reserves colon as a delimiter, i.e. 
"filename:streamname:streamtype", and stream names can include wildcards, pipe, 
and control characters. For example:

>>> control = '\a\b\t\n\v\f\r'
>>> special = '*?<>"|'
>>> dirname = 'C:\\Temp\\nametest'
>>> filename = f'{dirname}\\spam'
>>> streamname = f'{filename}:{control}{special}'
>>> os.makedirs(dirname, exist_ok=True)
>>> streamname
'C:\\Temp\\nametest\\spam:\x07\x08\t\n\x0b\x0c\r*?<>"|'
>>> open(streamname, 'w').close()

We can use PowerShell (pwsh) to verify the existence of the stream:

>>> cmd = f'pwsh -c (gi "{filename}" -stream *)[1].Stream'
>>> subprocess.check_output(cmd, text=True).rstrip()
'\x07\x08\t\n\x0b\x0c\n*?<>"|'

In terms of device namespaces, a device that is not mounted by a filesystem can 
implement practically whatever namespace it wants. But considering "//./" 
device paths are normalized Windows paths, device namespaces should reserve 
slash, since the system translates slash to backslash.

[1] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39514] http://sphinx.pocoo.org/

[Mariatta]

Mariatta  added the comment:

Hmm the fix should have been included in release 2020.1, which was release a 
couple weeks ago.

--
nosy: +Mariatta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39518] Dark theme

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This seems to be more of an issue relevant to python-docs-theme which is 
maintained separately : https://github.com/python/python-docs-theme

--
nosy: +mdk, xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39518] Dark theme

[Vitaly Zdanevich]

Change by Vitaly Zdanevich :


--
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39518] Dark theme

[Vitaly Zdanevich]

New submission from Vitaly Zdanevich :

Please save our eyes. And batteries. Do not ignore this property of useragent 
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

--
assignee: docs@python
components: Documentation
messages: 361177
nosy: Vitaly Zdanevich, docs@python
priority: normal
severity: normal
status: open
title: Dark theme

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39517] runpy calls open_code with Path object

[Tomas Ravinskas]

New submission from Tomas Ravinskas :

runpy accepts Path like objects but open_code seems to only accept strings, so 
calling open_code with Path object throws TypeError.
I think runpy should call str() on all path passed to open_code.
The relevant line is 232 in runpy.py in function _get_code_from_file.

--
components: Library (Lib)
messages: 361176
nosy: Tomas Ravinskas
priority: normal
severity: normal
status: open
title: runpy calls open_code with Path object
type: crash
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you Michael. Sorry, I just missed that you are working on your PR.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Alex Henrie]

Alex Henrie  added the comment:

Sorry about that, I didn't notice that GCC's -Wall option emits a warning about 
this. I just added the extra sets of parentheses.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Michael Felt  added the comment:

Blinded - got the numbers wrong!

So, again: Thanks for PR 18302. I followed your lead and made the additional 
changes and posted as PR 18303 in the hope this is easier for all.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Michael Felt  added the comment:

Thanks again for PR 18202. I followed your lead and made the additional changes 
and posted as PR 18203.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +17680
pull_request: https://github.com/python/cpython/pull/18303

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39516] ++ does not throw a SyntaxError

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Marco, this is no more of a defect than `x*-y` or `a&~b`. It is a binary 
operator followed by an unary operator, just like `x--y`, `x/-y`, 
`x+-y`, `x**-y` etc. Python has at least three unary operators and at 
least 17 binary operators so in total there are 51 possible legal 
combinations of a binary operator followed by an unary operator.

`++` isn't special, it's not unique, or a defect, or a bug.

> 1++
>   ^
> SyntaxError: invalid syntax

As a programmer with more than 10 years experience, you should know that 
this example is a syntax error because you are missing the right hand 
operand, not because `++` has no meaning. You would get precisely the 
same syntax error with `2*` or `2==`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Michael Felt  added the comment:

Here is the patch I am working on.

I appreciate your example on how to deal with the undefined variables. I had 
done that incorrectly initially.

--
Added file: https://bugs.python.org/file48876/bpo-39020-AIX.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Michael Felt  added the comment:

Have looked at your PR. It will not work on AIX because AIX libcurses is 
missing all four new functions.

Once I finished my test on AIX - shall I add my patch as a file here, so you 
can integrate into yours?

I hope that is easier than two PRs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39516] ++ does not throw a SyntaxError

[Marco Sulla]

Marco Sulla  added the comment:

> This is not a bug
No one said it's a bug. It's a defect.

> This has been part of Python since version 1
There are many things that was part of Python 1 that was removed.

> `++` should never be an operator in the future, precisely because it already 
> has a meaning today

This is not a "meaning". `++` means nothing. Indeed

>>> 1++
  File "", line 1
1++
  ^
SyntaxError: invalid syntax

> The first expression is not "unreadable". The fact that you were able to read 
> it and diagnose it [...]

The fact I understood it it's because I'm a programmer with more than 10 years 
of experience, mainly in Python. And I discovered this defect by acccident, 
because I wanted to write `a += b` and instead I wrote `a ++ b`. And when 
happened, I didn't realized why it didn't raised a SyntaxError or, at least, a 
SyntaxWarning. I had to take some minutes to realize the problem. 

So, in my "humble" opinion, it's *highly* unreadable and surprising.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Michael Felt  added the comment:

removed 3.8, this is new for 3.9.

Have established that all four functions added in issue38132 do not exist in 
stock AIX libcurses.a

Was working on my own PR, but shall look at yours first.

--
versions:  -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39378] partial of PickleState struct should be traversed.

[hai shi]

Change by hai shi :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

NetBSD also uses non-ncurses implementation of curses, but it supports 
ESCDELAY, set_escdelay(), etc. This is not a difference between ncurses and 
non-ncurse, but a problem specific to the AIX implementation of curses.

Please check that PR 18302 fixes the build.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +17679
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18302

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39516] ++ does not throw a SyntaxError

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is not a bug, as you have pointed out yourself you are using a binary plus 
and a unary plus operator in the same expression.

This has been part of Python since version 1, and with operator overloading 
`obj + +thing` could mean whatever the objects want the two operators to mean. 
Unary plus is not necessarily a no-op. For example, the Decimal class gives a 
meaning to unary plus.

`++` should never be an operator in the future, precisely because it already 
has a meaning today (either two unary pluses, or binary plus followed by unary 
plus). Even if the compiler could distinguish between the cases, the human 
reader would not.

The first expression is not "unreadable". The fact that you were able to read 
it and diagnose it yourself as a binary operator followed by a unary operator 
proves that you can, in fact, read it. And it probably wasn't that hard to 
understand. (It wasn't for me.)

It would be easier to read if you used spaces around the binary plus and no 
space between the unary plus and its operand, but it can still be read and 
understood even with the unusual spacing.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26789] asyncio: Please do not log during shutdown

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner
title: Please do not log during shutdown -> asyncio: Please do not log during 
shutdown

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[STINNER Victor]

STINNER Victor  added the comment:

Recently, Petr Viktorin proposed immortal singletons in my latest "Pass the 
Python thread state to internal C functions" thread on python-dev list:
https://mail.python.org/archives/list/python-...@python.org/message/RAVSH7HYHTROXSTUR3677WGTCTEO6FYF/

In 2004,  Jewett, Jim J proposed:

"What if a few common (constant, singleton) objects (such as None, -1, 0, 1) 
were declared immortal at compile-time?"

https://mail.python.org/archives/list/python-...@python.org/thread/XWGRUATMRAVXXZKQ7QA2YX22KI55T7P5/#OQO7DWRVH7IIOE4RUJ2ZR7S5UT6WOCPS

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[STINNER Victor]

STINNER Victor  added the comment:

I vaguely recall discussions about immortal Python objects.

(*) Instagram gc.freeze()

* https://docs.python.org/dev/library/gc.html#gc.freeze
* 
https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172

(*) Python immortal strings

* PyUnicode_InternImmortal()
* SSTATE_INTERNED_IMMORTAL
* They are only destroyed if Python is compiled with Valgrind or Purify 
support: unicode_release_interned() function

(*) COUNT_ALLOCS

* When Python is built with COUNT_ALLOCS macro defined, types are immortal
* Many tests have to be skipped if COUNT_ALLOCS is used
* I plan to remove COUNT_ALLOCS feature in bpo-39489 :-)

(*) Static types

* Types which are not allocated on the heap but "static" are immortal
* These types cause various issues and should go away
* For example, they are incompatible with multi-phase initialization module 
(PEP 489) and stable ABI (PEP 384)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39020] [AIX] module _curses fails to build since ESCDELAY has been added

[Michael Felt]

Michael Felt  added the comment:

Adding 3.8 before I post a PR - as I think the initial merge that introduced 
the regression was before master was considered 3.9.

--
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)

[Jeremy Kloth]

Jeremy Kloth  added the comment:

> The problem is to make Py_INCREF/Py_DECREF efficient.

That is exactly why I didn't propose a change to them.  The singletons
still are refcounted as usual, just that their ob_refcnt is ignored.
If they somehow reach 0, they just "resurrect" themselves and ignore
the regular collection behavior.  In the presence of multiple
DECREF'ers, the ob_refcnt field is garbage, but that is OK as it is
effectively ignored.  Practicality vs Purity and all that.

> Last time someone tried to use an atomic variable for ob_refcnt, it was 20% 
> slower if I recall correctly. If many threads start to update such atomic 
> variable, the CPU cacheline of common singletons like None, True and False 
> can quickly become a performance bottleneck.

Exactly so, hence why I chose the simple solution of effectively
ignoring ob_refcnt.

> On the other side, if each interpreter has its own objects, there is no need 
> to protect ob_refcnt, the interpreter lock protects it.

My solution also does not need any protection around ob_refcnt.

--
nosy: +jeremy.kloth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34793] Remove support for "with (await asyncio.lock):"

[Andrew Svetlov]

Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34793] Remove support for "with (await asyncio.lock):"

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 90d9ba6ef10af32e8dfe0649789c3a8ccf419e95 by Andrew Svetlov in 
branch 'master':
bpo-34793: Drop old-style context managers in asyncio.locks (GH-17533)
https://github.com/python/cpython/commit/90d9ba6ef10af32e8dfe0649789c3a8ccf419e95


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39516] ++ does not throw a SyntaxError

[Marco Sulla]

New submission from Marco Sulla :

Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01) 
[GCC 9.2.1 20190909] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 ++ 2
3

This is probably because the interpreter reads:

1 + +2

1. ++ could be an operator in future. Probably not. Probably never. But you 
never know.
2. A space between an unary operator and the object should not be allowed
3. the first expression is clearly unreadable and hard to understand, so 
completely unpythonic

--
components: Interpreter Core
messages: 361159
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: ++ does not throw a SyntaxError
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39298] add BLAKE3 to hashlib

[Jakub Stasiak]

Change by Jakub Stasiak :


--
nosy: +jstasiak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

In general I agree with Raymond, although I am warmer to this feature. And I 
think we should have a mechanism to deprecate not only options, but subcommands.

* The warnings module is used for warning about the use of API. It outputs the 
file and the line number of the caller to help the developer to fix his code. 
It allows to hide warnings from non-developers.

But warnings about deprecated CLI options and commands are purposed to be shown 
to the user of the CLI. They should not contain references to source code, 
because it is not the cause of the warning. The argparse module should use the 
same mechanism for warnings and errors: output to stderr.

* I do not understand the purpose of deprecated_pending. The feature is either 
deprecated or not. If it is deprecated, using it will produce a warning. If it 
is not deprecated -- no warning. In case of silent deprecation you can manually 
add a note in the help.

* I am not sure about deprecated_reason. We do not have a way to specify error 
message for standard errors (such like about missed required argument). If you 
need a custom warning, do not use the standard deprecation mechanism and emits 
a warning manually.

* As for moving the output of a warning to post-parsing logic, this is not 
always convenient and possible.

Let you have options "--verbose" which increments the verbosity level and 
"--verbosity-level" which sets it directly. One of them is deprecated. We can't 
easily use a post-parsing logic because they set the same destination. In this 
case we can workaround this by rewriting the logic to use different 
destinations, but there this is not always possible. Imagine you have options 
--add and --append which append the argument to the list and want to deprecate 
one of them. You can't use different lists and merge them in post-parsing, 
because the relative order matters.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39464] Allow translating argparse error messages

[hai shi]

hai shi  added the comment:

Users interact with console's output, so translated the output info is fine to 
me.
Hi，raymond、paul. What's your opinion?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39464] Allow translating argparse error messages

[hai shi]

hai shi  added the comment:

Paste José's comment from PR17169:

This message isn't used (only?) in exceptions... it's a message that is given 
to the console, to notify the user when she didn't provide correct parameters. 
For example:
 
```
$ python3 ./drt.py -l
Uso: ./drt.py [-h] [-l LONG_MIN] [-L LONG_MAX] [-v] [-V]
   entrada.json [salida.tok]
./drt.py: error: argument -l/--min-length: se esperaba un parámetro
```

These are console messages localized into Spanish. The "error:" part is 
translatable, but it's the same word in Spanish than in English. The "argument" 
part is what isn't translatable, and it's taken from this "exception".

I confirmed that my proposed patch, translating that particular string, allows 
giving a fully localized console output to the user in Spanish, such as:

`./drt.py: error: parámetro -l/--min-length: se esperaba un parámetro`

--
nosy: +shihai1991

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[hai shi]

hai shi  added the comment:

IMHO, cli should only support atomic function.What is atomic functin? (if 
downstream software's feature can not keep alive without upstream fucntion, it 
must be an atomic function).

--
nosy: +shihai1991 -4383

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com