date:20210323



D Levine  added the comment:

I think that would make the most sense, yes.

--

___
Python tracker 

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

[issue43607] urllib's request.pathname2url not compatible with extended-length Windows file paths

2021-03-23 Thread Eryk Sun



Eryk Sun  added the comment:

> I suppose the most reasonable behavior is to strip out the "\\?\" before 
> attempting the conversion as the path is sensible and parsable without 

Okay, so you're not looking to preserve the fact that it's a \\?\ verbatim path 
in the URI. You just want to automatically convert from verbatim \\?\X: or 
\\?\UNC\server\share to normal form. Devices other than drive letters and "UNC" 
wouldn't be supported.

--

___
Python tracker 

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

[issue43607] urllib's request.pathname2url not compatible with extended-length Windows file paths



D Levine  added the comment:

I really meant 255 characters not 256 because I was leaving three for ":/". I suppose the most reasonable behavior is to strip out the "\\?\" 
before attempting the conversion as the path is sensible and parsable without 
that, as opposed to the current behavior which is to  crash. The practical 
benefit is to permit the function to work on a wider range of inputs than 
currently is possible for essentially no cost.

--

___
Python tracker 

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

[issue43610] Ctrl C makes interpreter exit

2021-03-23 Thread Xinmeng Xia



New submission from Xinmeng Xia :

Python interpreter will exit when using Ctrl C to interrupt some Python module 
functions with read operations. e.g.  sndhdr.what(0), 
pdb.find_function('abs/'*10,False), mimetypes.read_mime_types(0).  This is 
not the expected behavior.  Ctrl C is to raise a KeyboardInterrupt, it should 
not crash Python and make interpreter exit.

Reproduce:
1. type 'python3' in command console;
2. type 'import sndhdr;sndhdr.what(0)'
3. type ctrl C

Expected behavior:  type ctrl c, raise a KeyboardInterrupt,  Python does not 
exit.

xxm@xxm-System-Product-Name:~$ python
Python 3.9.2 (default, Mar 12 2021, 15:08:35)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
KeyboardInterrupt
>>>


Unexpected behavior:  type ctrl c, raise a KeyboardInterrupt, Python exits.
===
xxm@xxm-System-Product-Name:~$ python
Python 3.9.2 (default, Mar 12 2021, 15:08:35)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sndhdr;sndhdr.what(0)
^CTraceback (most recent call last):
  File "", line 1, in 
  File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/sndhdr.py", line 54, in what
res = whathdr(filename)
  File "/home/xxm/Desktop/apifuzz/Python-3.9.2/Lib/sndhdr.py", line 61, in 
whathdr
h = f.read(512)
KeyboardInterrupt
>>>

xxm@xxm-System-Product-Name:~$
===

System: Ubuntu 16.04

--
components: Library (Lib)
messages: 389431
nosy: xxm
priority: normal
severity: normal
status: open
title: Ctrl C makes interpreter exit
type: crash
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

[issue43607] urllib's request.pathname2url not compatible with extended-length Windows file paths

2021-03-23 Thread Eryk Sun



Eryk Sun  added the comment:

RFC8089 doesn't specify "a mechanism for translating namespaced paths ["\\?\" 
and "\\.\"] to or from file URIs", and the Windows shell doesn't support them. 
So what's the practical benefit of supporting them in nturl2path?

> Windows file paths are limited to 256 characters,

Classically, normal filepaths are limited to MAX_PATH - 1 (259) characters, in 
most cases, except for a few cases in which the limit is even smaller. 

For a normal filepath, the API replaces slashes with backlashes; resolves 
relative paths; resolves "." and ".." components; strips trailing dots and 
spaces from the final path component; and, for relative paths and DOS 
drive-letter paths, reserves DOS device names in the final path component (e.g. 
CON, NUL). 

The kernel supports filepaths with up to 32,767 characters, but classically 
this was only accessible by using a verbatim \\?\ filepath, or by using 
workarounds based on substitute drives or filesystem mountpoints and symlinks.

With Python 3.6+ in Windows 10, if long paths are enabled in the system, normal 
filepaths support up to the full 32,767 characters in most cases. The need for 
the \\?\ prefix is thus limited to the rare case when a verbatim path is 
required, or when a filepath has to be passed to a legacy application that 
doesn't support long paths.

--
nosy: +eryksun

___
Python tracker 

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

[issue43609] ast.unparse-ing a FunctionType gives ambiguous result

2021-03-23 Thread midori



New submission from midori :

Hi all, this is probably my first issue here, so don't blame me if I do 
something wrong lol

The ast.FunctionType gives syntax like (a, b) -> c for function types, this is 
ok, and also since Python 3.10 we can use X | Y to denote unions, this is ok. 
So Given the following two trees:

fun1 = ast.FunctionType(
argtypes=[],
returns=ast.BinOp(
left=ast.Name(id='int'),
op=ast.BitOr(),
right=ast.Name(id='float'),
)
)
fun2 = ast.BinOp(
left=ast.FunctionType(
argtypes=[],
returns=ast.Name(id='int'),
),
op=ast.BitOr(),
right=ast.Name(id='float'),
)

Calling:

print(ast.unparse(fun1))
print(ast.unparse(fun2))

The results are these:

() -> int | float
() -> int | float

So there is some ambiguity. By feeding this string to 
ast.parse(mode='func_type'), I know that it means "returning a union".

Don't know if there is any impact to simply add a pair of parens, or does this 
problem even matters at all.

I tested it using Python 3.10 a6 and Python 3.9.2.

--
components: Library (Lib)
messages: 389429
nosy: Batuhan Taskaya, cleoold
priority: normal
severity: normal
status: open
title: ast.unparse-ing a FunctionType gives ambiguous result
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue43608] `bytes_concat` and Buffer cleanup

2021-03-23 Thread Sebastian Berg



New submission from Sebastian Berg :

`pybytes_concate` currently uses the following code to get the data:

va.len = -1;
vb.len = -1;
if (PyObject_GetBuffer(a, , PyBUF_SIMPLE) != 0 ||
PyObject_GetBuffer(b, , PyBUF_SIMPLE) != 0) {
PyErr_Format(PyExc_TypeError, "can't concat %.100s to %.100s",
 Py_TYPE(b)->tp_name, Py_TYPE(a)->tp_name);
goto done;
}

I don't actually know if it is realistically possible to issues here (I ended 
up here by chasing the wrong thing).  But this (and the identical code in 
`bytearray`) strictly rely on `view->len` not being modified on error (or else 
may not clean `va`)!

That seems wrong to me?  Although, I now saw that `PyBuffer_GetBuffer` says:

If the exporter cannot provide a buffer of the exact type, it MUST raise 
PyExc_BufferError, set view->obj to NULL and return -1.

Pretty much all code in NumPy (and cpython as far as I can tell), will 
guarantee that `obj` (and `len` probably) is untouched on error, but it will 
not set it to NULL!

I can see some wisdom in NULL'ing `view->obj` since it means the caller can 
call `PyBuffer_Release` unconditionally (but then we have to explicitly do 
that!).  But realistically, it seems to me the realistic thing is to say that a 
caller must never release an unexported buffer and make no assumption about its 
content?

(Which doesn't mean I won't ensure NumPy will keep `len` and `obj` unmodified 
or NULL `obj` on error.)

--
components: C API
messages: 389428
nosy: seberg
priority: normal
severity: normal
status: open
title: `bytes_concat` and Buffer cleanup
versions: Python 3.10, Python 3.9

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Pablo Galindo Salgado  added the comment:


New changeset a02683ac38183fa3a45c32319dfd329c5e622f0e by Pablo Galindo in 
branch 'master':
bpo-31861: Fix reference leak in builtin_anext_impl() (GH-25008)
https://github.com/python/cpython/commit/a02683ac38183fa3a45c32319dfd329c5e622f0e


--

___
Python tracker 

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

[issue43606] PySimpleGUI: initial huge window & no widgets visible

2021-03-23 Thread FRANK BENNETT



FRANK BENNETT  added the comment:

How about the following - title ok but no label visible ?

# t8.py
import tkinter as tk

class Application(tk.Tk):
def __init__(self):
tk.Tk.__init__(self)
self.geometry('500x500')
self.title('Your first App')

first_label = tk.Label(self, text = "I'm a cool App!!", font=10, 
bg="black",fg="red" )
first_label.pack(pady= 2, padx = 2)

app = Application()
app.mainloop()

--

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Pablo Galindo Salgado  added the comment:

Fixed by PR25008

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

[issue43244] Move PyArena C API to the internal C API



STINNER Victor  added the comment:

Ok, the whole C API related to parser, compiler, AST, ASDL and PyArena moved to 
the internal C API. So we will have more freedom to evolve it!

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

[issue43244] Move PyArena C API to the internal C API



STINNER Victor  added the comment:


New changeset 8370e07e1e5b626e78ddc7aadbfaf248976c4454 by Victor Stinner in 
branch 'master':
bpo-43244: Remove the pyarena.h header (GH-25007)
https://github.com/python/cpython/commit/8370e07e1e5b626e78ddc7aadbfaf248976c4454


--

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Change by Pablo Galindo Salgado :


--
pull_requests: +23766
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25008

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



STINNER Victor  added the comment:

I reopen the issue.

The commit f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57 introduced a reference leak:

$ ./python -m test -R 3:3 test_asyncgen

0:00:00 load avg: 4.75 Run tests sequentially
0:00:00 load avg: 4.75 [1/1] test_asyncgen
beginning 6 repetitions
123456
..
test_asyncgen leaked [72, 72, 72] references, sum=216
test_asyncgen leaked [30, 30, 30] memory blocks, sum=90
test_asyncgen failed

== Tests result: FAILURE ==

1 test failed:
test_asyncgen

Total duration: 6.0 sec
Tests result: FAILURE

--
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue43244] Move PyArena C API to the internal C API



Change by STINNER Victor :


--
pull_requests: +23765
pull_request: https://github.com/python/cpython/pull/25007

___
Python tracker 

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

[issue41064] Specialise syntax error of **dict in f-string field



Pablo Galindo Salgado  added the comment:

> I don't recall if this is really only a "skip leading whitespace" problem, or 
> if there's some other reason they're required.

IIRC, this forces the expression inside to be parsed as an expression. This 
helps the quite a lot the parser. For instance, detecting a bare **x without 
grouping is more difficult, even with the old parser. With parentheses it must 
be an expression so is easier to disambiguate.

--

___
Python tracker 

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

[issue41064] Specialise syntax error of **dict in f-string field



Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Pablo Galindo Salgado  added the comment:


New changeset 919d42d477093154a30b55d9d79f023dbbe5614a by Pablo Galindo in 
branch 'master':
bpo-31861: Fix possible crash in PyAnextAwaitable_New (GH-25005)
https://github.com/python/cpython/commit/919d42d477093154a30b55d9d79f023dbbe5614a


--

___
Python tracker 

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

[issue43244] Move PyArena C API to the internal C API



STINNER Victor  added the comment:


New changeset 57364ce34e0492fbc8b0a6b8c882f384bb489457 by Victor Stinner in 
branch 'master':
bpo-43244: Remove parser_interface.h header file (GH-25001)
https://github.com/python/cpython/commit/57364ce34e0492fbc8b0a6b8c882f384bb489457


--

___
Python tracker 

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

[issue43452] Microoptimize PyType_Lookup for cache hits



Pablo Galindo Salgado  added the comment:


New changeset a054f6b2b1d9f75edfb5ec2247bbf60f07491977 by Pablo Galindo in 
branch 'master':
bpo-43452: Document the PyType_Lookup optimizations in the What's New for 3.10 
(GH-24949)
https://github.com/python/cpython/commit/a054f6b2b1d9f75edfb5ec2247bbf60f07491977


--

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Pablo Galindo Salgado  added the comment:


New changeset d9692027f41ee7600fe401c066617ebfc8bac930 by Pablo Galindo in 
branch 'master':
bpo-31861: Complete the C-API docs for PyObject_GetAiter and PyAiter_Check 
(GH-25004)
https://github.com/python/cpython/commit/d9692027f41ee7600fe401c066617ebfc8bac930


--

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Change by Pablo Galindo Salgado :


--
pull_requests: +23763
pull_request: https://github.com/python/cpython/pull/25005

___
Python tracker 

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

[issue43244] Move PyArena C API to the internal C API



STINNER Victor  added the comment:


New changeset a81fca6ec8e0f748f8eafa12fb12cf9e12df465c by Victor Stinner in 
branch 'master':
bpo-43244: Add pycore_compile.h header file (GH-25000)
https://github.com/python/cpython/commit/a81fca6ec8e0f748f8eafa12fb12cf9e12df465c


--

___
Python tracker 

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

[issue31861] add aiter() and anext() functions



Change by Pablo Galindo Salgado :


--
nosy: +pablogsal
nosy_count: 12.0 -> 13.0
pull_requests: +23762
pull_request: https://github.com/python/cpython/pull/25004

___
Python tracker 

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

[issue43607] urllib's request.pathname2url not compatible with extended-length Windows file paths



Change by D Levine :


--
type: crash -> behavior

___
Python tracker 

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

[issue43607] urllib's request.pathname2url not compatible with extended-length Windows file paths



New submission from D Levine :

Windows file paths are limited to 256 characters, and one of Windows's 
prescribed methods to address this is to prepend "\\?\" before a Windows 
absolute path (see: 
https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation)

urllib.request.pathname2url raises an error on such paths as this function 
calls nturl2path.py's pathname2url function which explicitly checks that the 
number of characters before the ":" in a Windows path is precisely one, which 
is, of course, not the case if you are using an extended-length path (e.g. 
"\\?\C:\Python39").

As a result, urllib cannot handle pathname2url conversion for some valid 
Windows paths.

--
components: Windows
messages: 389415
nosy: levineds, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib's request.pathname2url not compatible with extended-length 
Windows file paths
type: crash
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

[issue31861] add aiter() and anext() functions

2021-03-23 Thread Guido van Rossum



Change by Guido van Rossum :


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

[issue31861] add aiter() and anext() functions

2021-03-23 Thread Guido van Rossum



Guido van Rossum  added the comment:


New changeset f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57 by Joshua Bronson in 
branch 'master':
bpo-31861: Add aiter and anext to builtins (#23847)
https://github.com/python/cpython/commit/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57


--
nosy: +gvanrossum

___
Python tracker 

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

[issue32592] Drop support of Windows Vista and Windows 7

2021-03-23 Thread Alexey Izbyshev



Alexey Izbyshev  added the comment:

> If Win8-only calls are not used, then presumably it should still build and 
> run on Windows 7, presumably with the flag flipped back to Win7. And if there 
> are Win8-only calls used and the flag is set to Win7+, I assume that the MSVC 
> compiler will catch any instances of Win8-only calls at build time? Is this 
> understanding correct?

It's the latter. In the patch, calls to functions like PathCchCanonicalizeEx(), 
which had previously been conditional on runtime availability of those 
functions, were made direct. Those functions are not from UCRT (so you can't 
just distribute it to regain Windows 7 support) and are not available in 
Windows 7.

There was also another patch that adds a check to Python 3.9+ installer that 
prevents installation on Windows 7 (but again, even if you take the Windows 
"embedded" distro instead of the installer, it won't run due to Win8-only 
functions).

> If the latter is true, its very likely a lost cause. However, if the former 
> is the case, then at least devs using Python 3.9+ on Windows 7 will be able 
> to easily build their own versions with support, though that could change at 
> any time.

For now, it's not entirely lost cause in the sense that the number of 
Win8-specific patches and their size is very small (I'm not aware of anything 
not already mentioned, but I may be not up-to-date). So an interested party can 
probably revert them locally without much hassle.

> For those in the know, have there been a lot of reports/discontent 
> surrounding the dropping of support in Py3.9, by anyone aware of that? 

I semi-casually follow the bug tracker and remember only bpo-41412 and 
bpo-42027.

Personally, I do consider tying of Windows support in CPython to arbitrary 
support periods set by Microsoft unfortunate, and it's also true that 
Win8-specific changes I'm aware of are not critical and don't remove any 
significant maintenance burden. For now, both relative and absolute usage of 
Windows 7 is huge and hard to ignore, so developers who use CPython in their 
own software are faced with an unpleasant choice of sticking to 3.8 or dropping 
Win 7. (I'm one of them since software I work on has to run in build 
environments setup for other projects, and such environments routinely stick to 
old OS versions due to breakage on updates). But this is what we have according 
to PEP 11, and a little grumbling here certainly won't change that :)

--

___
Python tracker 

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

[issue43595] Can not add a metclass that inherits both ABCMeta & ABC to a Union

2021-03-23 Thread Jacob Nilsson



Jacob Nilsson  added the comment:

Hi, I tried both code snippets, and they work for me with the output:

typing.Union[str, abc.ABC]

For your second code snippet.

Tested on 3.7.6 (IPython though) on a Windows machine, can test it on Linux 
tomorrow.

--
nosy: +ajoino

___
Python tracker 

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

[issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param

2021-03-23 Thread Erlend Egeberg Aasland



Erlend Egeberg Aasland  added the comment:

Terry, I've created GH-25003 based on your suggested changes.

--

___
Python tracker 

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

[issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param

2021-03-23 Thread Erlend Egeberg Aasland



Change by Erlend Egeberg Aasland :


--
keywords: +patch
nosy: +erlendaasland
nosy_count: 6.0 -> 7.0
pull_requests: +23761
pull_request: https://github.com/python/cpython/pull/25003

___
Python tracker 

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

[issue43535] Make str.join auto-convert inputs to strings.



Change by Raymond Hettinger :


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

[issue43535] Make str.join auto-convert inputs to strings.

2021-03-23 Thread Jacob Nilsson


Jacob Nilsson  added the comment:

For what my opinion is worth, I agree with Grégory's suggestion because the ',' 
part of ','.join(...) is almost as unintuitive as the problems Raymond's 
suggestions are trying to fix.

I was going to suggest a builtin to work on both str and bytes, like 
join(sep=None, strtype=str, *strings) but that interface looks pretty bad...

I think joinstr/joinbytes according to Grégory's suggestion (perhaps as 
classmethods of str/bytes?) would make the most sense.

--
nosy: +ajoino

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real



Change by Raymond Hettinger :


--
nosy: +tim.peters

___
Python tracker 

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

[issue43466] ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs



Change by Christian Heimes :


--
pull_requests: +23760
pull_request: https://github.com/python/cpython/pull/25002

___
Python tracker 

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

[issue43606] PySimpleGUI: initial huge window & no widgets visible

2021-03-23 Thread E. Paine



Change by E. Paine :


--
nosy:  -pau

___
Python tracker 

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

[issue43606] PySimpleGUI: initial huge window & no widgets visible

2021-03-23 Thread E. Paine



E. Paine  added the comment:

I have removed the Windows component as the issue reported seems to be on 
Ubuntu (but I don't like removing others from the nosy, so have left that 
alone).

Tkinter does no initial window configuration created through either `Tk()` or 
`Toplevel()` as this is all handled by Tk (though I don't believe that would do 
the behaviour you describe). I cannot reproduce the issue (either with or 
without the 'size' argument) but suggest you take it up with the PySimpleGui 
team as they may be doing some custom configuration.

--
components:  -Windows
nosy: +epaine, pau, serhiy.storchaka
title: initial huge window  && no widgets visible -> PySimpleGUI: initial huge 
window & no widgets visible

___
Python tracker 

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

[issue43244] Move PyArena C API to the internal C API



Change by STINNER Victor :


--
pull_requests: +23759
pull_request: https://github.com/python/cpython/pull/25001

___
Python tracker 

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

[issue43244] Move PyArena C API to the internal C API



Change by STINNER Victor :


--
pull_requests: +23758
pull_request: https://github.com/python/cpython/pull/25000

___
Python tracker 

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

[issue43244] Move PyArena C API to the internal C API



STINNER Victor  added the comment:


New changeset 94faa0724f8cbae6867c491c8e465e35f4fdbfbb by Victor Stinner in 
branch 'master':
bpo-43244: Remove ast.h, asdl.h, Python-ast.h headers (GH-24933)
https://github.com/python/cpython/commit/94faa0724f8cbae6867c491c8e465e35f4fdbfbb


--

___
Python tracker 

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

[issue43604] Fix tempfile.mktemp()

2021-03-23 Thread David Lukeš


David Lukeš  added the comment:

> You can use TemporaryDirectory.

That was actually the first approach I tried :) I even thought this could be 
used to make `mktemp` safe -- just create the name in a `TemporaryDirectory`.

However, after reading through the mailing list thread, I realized this just 
restricts the potential collision/hijacking to misbehaving/malicious processes 
running under the same user or under the super user. But the core problem with 
too easily guessable filenames (= not random enough, or not at all, as in your 
example) remains. Correct me if I'm wrong though.

Sorry, I should probably have mentioned this in OP. I thought about doing so, 
but then it turned out very long even without it, so I decided it would be 
better to discuss it only if someone else mentions it.

--

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports



STINNER Victor  added the comment:

Ok, the most important changes have been merged. Thanks everyone who helped on 
this large project! See also my summary email on python-dev:
https://mail.python.org/archives/list/python-...@python.org/thread/I3OQTA3F66NQUN7CH2NHC5XZTO24QCIK/

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

[issue31907] doc: Clarify error message when attempting to call function via str.format()

2021-03-23 Thread Irit Katriel



Irit Katriel  added the comment:

I would suggest the following change in 
https://docs.python.org/3/library/string.html#format-string-syntax

replace the sentence:

The syntax is related to that of formatted string literals, but there are 
differences.

by:

The syntax is related to that of formatted string literals, but it is less 
sophisticated and, in particular, does not support arbitrary expressions.

Is this accurate? Is it enough?

--
nosy: +iritkatriel
title: Clarify error message when attempting to call function via str.format() 
-> doc: Clarify error message when attempting to call function via str.format()
versions: +Python 3.10 -Python 3.7

___
Python tracker 

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

[issue39572] [typing] TypedDict's 'total' argument is undocumented

2021-03-23 Thread Roundup Robot



Change by Roundup Robot :


--
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +23757
pull_request: https://github.com/python/cpython/pull/24999

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports



STINNER Victor  added the comment:


New changeset cd27af70d58161c59072e27a10e0e63dcbf0bccb by Victor Stinner in 
branch 'master':
bpo-41718: Update runpy startup time What's New (GH-24998)
https://github.com/python/cpython/commit/cd27af70d58161c59072e27a10e0e63dcbf0bccb


--

___
Python tracker 

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

[issue43606] initial huge window && no widgets visible

2021-03-23 Thread FRANK BENNETT



New submission from FRANK BENNETT :

with any PySimpleGUI, tkinter, tk, *.py

The initial window is huge & with a size no widgets are visible

fwb@fw:/s/opt/cpython$ uname -r
5.4.0-67-generic

fwb@fw:/s/opt/cpython$ cat /etc/issue
Ubuntu 20.04.2 LTS \n \l

fwb@fw:/s/opt/cpython$ ./python -V
Python 3.10.0a6+fwb@fw:/s/opt/cpython$ cat .git/config 
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://github.com/bennett78/cpython.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master


What sets initial window configuration ?

--
components: Tkinter, Windows
files: t4.py
messages: 389403
nosy: bennett78, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: initial huge window  && no widgets visible
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49906/t4.py

___
Python tracker 

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

[issue43604] Fix tempfile.mktemp()

2021-03-23 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

You can use TemporaryDirectory.

with tempfile.TemporaryDirectory() as dir:
fifo_path = os.path.join(dir, "fifo")
os.mkfifo(fifo_path, 0o600)
...

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports



Change by STINNER Victor :


--
pull_requests: +23756
pull_request: https://github.com/python/cpython/pull/24998

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports



STINNER Victor  added the comment:


New changeset bd9154a495434464283f74b660160f89930cd791 by Victor Stinner in 
branch 'master':
bpo-41718: runpy now imports pkgutil in functions (GH-24996)
https://github.com/python/cpython/commit/bd9154a495434464283f74b660160f89930cd791


--

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real

Sergey B Kirpichev  added the comment:

On Tue, Mar 23, 2021 at 01:03:47PM +, Mark Dickinson wrote:
> What do you think the result of `1.0 + Decimal(1)` should be, and
> more importantly why? Possible options are:
> 
> - Decimal('2')
> - 2.0 (a float)
> - a `TypeError` (as now)
> - some kind of horrible user-configurable-global-state-dependent answer

Decimal, with a some kind of "horrible
user-configurable-global-state-dependent answer" (Decimal
context): reverse conversion might be inexact.
Same, in principle, holds for 2-base multiprecision arithmetic
types like gmpy2.mpfr and mpmath.mpf.  "More powerfull data type,
claiming it implements numbers.Real - should know better."
That's the first option.

Maybe I (and authors of mentioned above packages) - do miss something
important.  (Oh, count on SageMath too.)
But do we have other examples of numbers.Real implementations (or
claiming to be such)?  If the numbers.Real does mean something like "only
python's builtin floats, but maybe with a different multiplication
algorithm" - that's hardly something that people may expect from
the docs.  Real numbers have a very specific mathematical meaning and
things like mpmath's mpf or Decimal fit this.

> Bear in mind that you have to pick a behaviour that's a good default
> choice for all potential application domains, and that's *hard*.

I think, that TypeError (a second option) might make sense too.  I'm not
sure that different implementations of numbers.Real must be interoperable (i.e.
without explicit conversions).  Such requirement clearly does make sense for
exact data types in the numerical tower (i.e. different
numbers.Rational implementations).

So, this implementation of the numbers tower:
  int (Integral) - Fraction (Rational) - float (Real) - complex (Complex)
doesn't look "more correct", than this:
  gmpy2.mpz - gmpy2.mpq - gmpy2.mpfr - gmpy2.mpc
regardless on how do "inexact" data types (e.g. float vs mpfr)
interoperate.  Same may be for the Decimal (but this is not a full tower):
  int - Fraction - Decimal.

--

___
Python tracker 

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

[issue43520] Make Fraction(string) handle non-ascii slashes

2021-03-23 Thread Carl Anderson


Carl Anderson  added the comment:

>The proposal I like is for a unicode numeric normalization functions that 
>return the ascii equivalent to exist.

@Gregory P. Smith 
this makes sense to me. That does feel like the cleanest solution. 
I'm currently doing s = s.replace("⁄","/") but it would be good to have a 
well-maintained normalization method that contained the all the relevant 
mappings as an independent preprocess step to Fraction would work well.

--

___
Python tracker 

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

[issue32592] Drop support of Windows Vista and Windows 7

2021-03-23 Thread C.A.M. Gerlach



C.A.M. Gerlach  added the comment:

In my limited understanding, all PR #15951 does is set a compiler macro to 
allow use of Win API calls present on >=Win8 instead of >=Win7. If Win8-only 
calls are not used, then presumably it should still build and run on Windows 7, 
presumably with the flag flipped back to Win7. And if there are Win8-only calls 
used and the flag is set to Win7+, I assume that the MSVC compiler will catch 
any instances of Win8-only calls at build time? Is this understanding correct?

If the latter is true, its very likely a lost cause. However, if the former is 
the case, then at least devs using Python 3.9+ on Windows 7 will be able to 
easily build their own versions with support, though that could change at any 
time. If the upside to supporting the latest Python versions on an EoL platform 
that is no longer receiving security updates but still has significant use is 
greater than the (seemingly pretty small) benefits of dropping support, then I 
imagine it would at least be conceivable to switch the flag back, though it 
probably is a lost cause now that a major version has been released without 
support and the buildbots have been presumably retired. At least third parties 
should be able to easily release patched versions, for now.

For those in the know, have there been a lot of reports/discontent surrounding 
the dropping of support in Py3.9, by anyone aware of that? 

However, I don't think it should be tied to the ESU date at all, as opposed to 
real-world usage of bleeding-edge Python on that version; ESU is a paid-only 
service for large corporate customers; if they're willing to pay through the 
nose for updates to their EoL OS and also need the latest bleeding-edge Python, 
surely they can fund the pittance required for maintenance or building it 
themselves.

All that said, I'll hold off on doing anything further until there's consensus. 
I'd think whatever we do it should be consistent, at least in the docs and 
installer; if dropping support in the code itself is more risk and pain than 
benefit, then that needn't be done.

--

___
Python tracker 

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

[issue37612] os.link(..., follow_symlinks=True) broken on Linux

2021-03-23 Thread Thomas Kluyver



Change by Thomas Kluyver :


--
nosy: +takluyver
nosy_count: 4.0 -> 5.0
pull_requests: +23755
pull_request: https://github.com/python/cpython/pull/24997

___
Python tracker 

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

[issue43573] [types] Document spec for types.ModuleType

2021-03-23 Thread Brett Cannon



Change by Brett Cannon :


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

[issue43605] Issue of scopes unclear in documentation, or wrongly implemented

2021-03-23 Thread Bruno Loff



New submission from Bruno Loff :

Python 3.9.2 seems to be giving me some unexpected difficulty evaluating 
generators inside evals. Here is the example:

```python
def func(l):
def get(i):
return l[i]


print(sum(get(i) for i in range(len(l # works as expected, prints 10
print(eval("get(0) + get(1) + get(2) + get(3)")) # works just fine, prints 
10

# if __globals is set to locals(), it still works, prints 10
print(eval("sum(get(i) for i in range(len(l)))", locals()))

# This will complain
print(eval("sum(get(i) for i in range(len(l)))"))

func([1,2,3,4])
```

The last line gives the following error

```
Traceback (most recent call last):
  File "/something/test_eval.py", line 28, in 
func([1,2,3,4])
  File "/something/test_eval.py", line 10, in func
print(eval("sum(get(i) for i in range(len(l)))"))  # this does not work... 
bug?
  File "", line 1, in 
  File "", line 1, in 

NameError: name 'get' is not defined
```

Any kind of generator-based code wont work. The following lines would give the 
same an error:
```
print(eval("sum(get(i) for i in range(len(l)))"), globals(), locals())
print(eval("[get(i) for i in range(len(l))]"))
print(eval("{i:get(i) for i in range(len(l))}"))
```


Any clue what is happening? The documentation on eval seems to give no insight 
on why this behavior is as is. This really feels like an issue, at the very 
least, it's an issue in the documentation.

--
messages: 389397
nosy: bruno.loff
priority: normal
severity: normal
status: open
title: Issue of scopes unclear in documentation, or wrongly implemented
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

[issue25716] typeobject.c call_method & call_maybe can leak references on 'func'

2021-03-23 Thread Irit Katriel



Irit Katriel  added the comment:

I believe this issue is out of date. There are no longer such functions as 
call_method and call_maybe. There are vectorcall_method and vectorcall_maybe, 
but they don't have that check for (args == NULL).

--
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports



Change by STINNER Victor :


--
pull_requests: +23754
pull_request: https://github.com/python/cpython/pull/24996

___
Python tracker 

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

[issue35930] Raising an exception raised in a "future" instance will create reference cycles

2021-03-23 Thread Jesús Cea Avión


Change by Jesús Cea Avión :


--
versions: +Python 3.10

___
Python tracker 

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

[issue35930] Raising an exception raised in a "future" instance will create reference cycles

2021-03-23 Thread Jesús Cea Avión


Change by Jesús Cea Avión :


--
assignee:  -> jcea

___
Python tracker 

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

[issue35930] Raising an exception raised in a "future" instance will create reference cycles

2021-03-23 Thread Jesús Cea Avión


Change by Jesús Cea Avión :


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

___
Python tracker 

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

[issue41718] test.regrtest has way too many imports



STINNER Victor  added the comment:


New changeset d72e8d487553c103bf2742e229f8266b515fd951 by Victor Stinner in 
branch 'master':
bpo-41718: subprocess imports grp and pwd on demand (GH-24987)
https://github.com/python/cpython/commit/d72e8d487553c103bf2742e229f8266b515fd951


--

___
Python tracker 

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

[issue43573] [types] Document spec for types.ModuleType

2021-03-23 Thread Brett Cannon



Change by Brett Cannon :


--
pull_requests: +23752
pull_request: https://github.com/python/cpython/pull/24994

___
Python tracker 

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

[issue43604] Fix tempfile.mktemp()

2021-03-23 Thread David Lukeš


David Lukeš  added the comment:

> A secure `mktemp` could be as simple as ...

Though in practice, I'd rather be inclined to make the change in 
`tempfile._RandomNameSequence`, so as to get the same behavior across the 
entire module, instead of special-casing `mktemp`. As Guido van Rossum points 
out (see 
), that 
would improve the security of all the names generated by the `tempfile` module, 
not just `mktemp`:

> Hm, the random sequence (implemented in tempfile._RandomNameSequence) is
> currently derived from the random module, which is not cryptographically
> secure. Maybe all we need to do is replace its source of randomness with
> one derived from the secrets module. That seems a one-line change.

--

___
Python tracker 

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

[issue43573] [types] Document spec for types.ModuleType

2021-03-23 Thread miss-islington



Change by miss-islington :


--
pull_requests: +23751
pull_request: https://github.com/python/cpython/pull/24993

___
Python tracker 

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

[issue43573] [types] Document spec for types.ModuleType

2021-03-23 Thread miss-islington



Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +23750
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24992

___
Python tracker 

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)

2021-03-23 Thread Felix C. Stegerman



Felix C. Stegerman  added the comment:

> The __getattr__ hack is not needed. You can reset the flags in a different, 
> more straight forward way

As mentioned, ZipFile._open_to_write() will modify the ZipInfo's .external_attr 
when it is set to 0.

> I just found another specific example in _open_to_write().  0 is a valid 
> value for zinfo.external_attr.  But this code always forces 0 to something 
> else:
>
> if not zinfo.external_attr:
> zinfo.external_attr = 0o600 << 16  # permissions: ?rw---

Your alternative doesn't seem to take that subsequent modification into account.

--

___
Python tracker 

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

[issue43604] Fix tempfile.mktemp()

2021-03-23 Thread David Lukeš


New submission from David Lukeš :

I recently came across a non-testing use case for `tempfile.mktemp()` where I 
struggle to find a viable alternative -- temporary named pipes (FIFOs):

```
import os
import tempfile
import subprocess as sp

fifo_path = tempfile.mktemp()
os.mkfifo(fifo_path, 0o600)
try:
proc = sp.Popen(["cat", fifo_path], stdout=sp.PIPE, text=True)
with open(fifo_path, "w") as fifo:
for c in "Kočka leze dírou, pes oknem.":
print(c, file=fifo)
proc.wait()
finally:
os.unlink(fifo_path)

for l in proc.stdout:
print(l.strip())
```

(`cat` is obviously just a stand-in for some useful program which needs to read 
from a file, but you want to send it input from Python.)

`os.mkfifo()` needs a path which doesn't point to an existing file, so it's not 
possible to use a `tempfile.NamedTemporaryFile(delete=False)`, close it, and 
pass its `.name` attribute to `mkfifo()`.

I know there has been some discussion regarding `mktemp()` in the relatively 
recent past (see the Python-Dev thread starting with 
). There 
has also been some confusion as to what actually makes it unsafe (see 
). Before 
the discussion petered out, it looked like people were reaching a consensus 
"that mktemp() could be made secure by using a longer name generated by a 
secure random generator" (quoting from the previous link).

A secure `mktemp` could be as simple as (see 
):

```
def mktemp(suffix='', prefix='tmp', dir=None):
if dir is None:
dir = gettempdir()
return _os.path.join(dir, prefix + secrets.token_urlsafe(ENTROPY_BYTES) + 
suffix)
```

There's been some discussion as to what `ENTROPY_BYTES` should be. I like 
Steven D'Aprano's suggestion (see 
) of 
having an overkill default just to be on the safe side, which can be overridden 
if needed. Of course, the security implications of lowering it should be 
clearly documented.

Fixing `mktemp` would make it possible to get rid of its hybrid deprecated (in 
the docs) / not depracated (in code) status, which is somewhat confusing for 
users. Speaking from experience -- when I realized I needed it, the deprecation 
notice led me down this rabbit hole of reading mailing list threads and 
submitting issues :) People could stop losing time worrying about `mktemp` and 
trying to weed it out whenever they come across it (see e.g. 
https://bugs.python.org/issue42278).

So I'm wondering whether there would be interest in:

1. A PR which would modify `mktemp` along the lines sketched above, to make it 
safe in practice. Along with that, it would probably make sense to undeprecate 
it in the docs, or at least indicate that while users should prefer `mkstemp` 
when they're fine with the file being created for them, `mktemp` is alright in 
cases where this is not acceptable.
2. Following that, possibly a PR which would encapsulate the new `mktemp` + 
`mkfifo` into a `TemporaryNamedPipe` or `TemporaryFifo`:

```
import os
import tempfile
import subprocess as sp

with tempfile.TemporaryNamedPipe() as fifo:
proc = sp.Popen(["cat", fifo.name], stdout=sp.PIPE, text=True)
for c in "Kočka leze dírou, pes oknem.":
print(c, file=fifo)
proc.wait()

for l in proc.stdout:
print(l.strip())
```

(Caveat: opening the FIFO for writing cannot happen in `__enter__`, it would 
have to be delayed until the first call to `fifo.write()` because it hangs if 
no one is reading from it.)

--
components: Library (Lib)
messages: 389393
nosy: David Lukeš
priority: normal
severity: normal
status: open
title: Fix tempfile.mktemp()
type: security
versions: Python 3.10

___
Python tracker 

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

[issue37405] socket.getsockname() returns string instead of tuple

2021-03-23 Thread Brent Gardner



Change by Brent Gardner :


--
pull_requests: +23749
pull_request: https://github.com/python/cpython/pull/24991

___
Python tracker 

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

[issue43603] spam

2021-03-23 Thread Mark Dickinson



Change by Mark Dickinson :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: safgf -> spam
type: performance -> 

___
Python tracker 

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

[issue18304] ElementTree -- provide a way to ignore namespace in tags and searches

2021-03-23 Thread Lars Hammarstrand



Lars Hammarstrand  added the comment:

Any update regarding this? 

We switched to lxml to make life easier but it would be useful if this 
functionality also was implemented in the standard library.

Wishlist: 
1. Flag to ignore all namespaces during find().
2. Ability to set default namespace the during find().
3. Clear existing namespaces similar to lxml cleanup_namespaces.

--
nosy: +Lars_Hammarstrand

___
Python tracker 

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

[issue14527] How to link with a non-system libffi?

2021-03-23 Thread Rupert Nash



Rupert Nash  added the comment:

Due to some major changes in setup.py around libffi, I've had to re-implement 
my patch - please see Github. I'd appreciate any comments so we can get this 
merged. Thanks!

--

___
Python tracker 

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

[issue43511] tkinter with Tk 8.6.11 is slow on macOS

2021-03-23 Thread E. Paine



E. Paine  added the comment:

This *appears* to be a Tk issue. I ran a benchmark (see attached) which 
repeatedly performed canvas actions. The first test ("clearing") clears the 
canvas, creates a rectangle, then calls both `update` and `update_idletasks`. 
The second test ("not clearing") is the same as the above but did not clear the 
canvas (causing rectangles to be drawn over each other). Here is a table of the 
results (times are per iteration in milliseconds):

++-+-+
| Tk Version | Python  | Wish|
|+--+--+--+--+
|| clearing | not clearing | clearing | not clearing |
++==+==+==+==+
| 8.6.8  | 6.6  | 41.4 | 4.2  | 16.2 |
++--+--+--+--+
| 8.6.11 | 37.0 | 37.1 | 36.1 | 36.1 |
++--+--+--+--+

A few notes:
- These were performed on a slow machine and results could be influenced by 
background CPU usage fluctuations
- Because it is a slow computer, I limited the iterations to just 1000 per test.
- Python version was 3.9.2
- Wish 8.6.8 was installed using an ActiveTcl binary whereas 8.6.11 was 
installed through homebrew

--
Added file: https://bugs.python.org/file49905/tkbench.zip

___
Python tracker 

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

[issue43603] safgf



Change by aaa dsghsu :


Removed file: https://bugs.python.org/file49903/442723

___
Python tracker 

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

[issue37405] socket.getsockname() returns string instead of tuple

2021-03-23 Thread Brent Gardner



Brent Gardner  added the comment:

This test was overlooked, and line 2052 should now be removed per the 
discussion here:

https://github.com/python/cpython/pull/14392#issuecomment-506133908

In short, getsockname() used to return `(interface, socket.AF_CAN)`, in which 
the socket.AF_CAN element was superfluous (also undocumented), so it was 
removed in the fix, and the tuple format was reinstated.

--

___
Python tracker 

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

[issue43603] safgf



Change by aaa dsghsu :


Added file: https://bugs.python.org/file49904/131970

___
Python tracker 

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

[issue43603] safgf



Change by aaa dsghsu :


Added file: https://bugs.python.org/file49903/442723

___
Python tracker 

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

[issue43603] safgf



Change by aaa dsghsu :


--
components: C API
files: 442724
nosy: aaadsghsu
priority: normal
severity: normal
status: open
title: safgf
type: performance
versions: Python 3.6
Added file: https://bugs.python.org/file49902/442724

___
Python tracker 

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

[issue15352] importlib.h should be regenerated when the marshaling code changes



Change by aaa dsghsu :


Added file: https://bugs.python.org/file49901/442723

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real

2021-03-23 Thread Mark Dickinson



Mark Dickinson  added the comment:

> Seems so, for a static typing.  But Python is a dynamically typed
> language, isn't?

I think we're talking at cross purposes. Static and dynamic typing have nothing 
to do with this.

What do you think the result of `1.0 + Decimal(1)` should be, and more 
importantly why? Possible options are:

- Decimal('2')
- 2.0 (a float)
- a `TypeError` (as now)
- some kind of horrible user-configurable-global-state-dependent answer

Bear in mind that you have to pick a behaviour that's a good default choice for 
all potential application domains, and that's *hard*. ("In the face of 
ambiguity ...", and all that.)

--

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real

Sergey B Kirpichev  added the comment:

On Tue, Mar 23, 2021 at 10:21:50AM +, Mark Dickinson wrote:
> Mark Dickinson  added the comment:
> > I assume, the reason is: there is no lossless conversion to float's (and 
> > vice verse).
> and in fact we _do_ have lossless conversion of floats to Decimal instances

Indeed, context precision doesn't affect this.  (But still, reversed
conversion is inexact in general).

> - it's not obvious what the *type* of the result of some_float + 
> some_other_decimal should be

Seems so, for a static typing.  But Python is a dynamically typed
language, isn't?

  >>> import gmpy2
  >>> gmpy2.mpfr('1.0') + 1.0
  mpfr('2.0')
  >>> 1.0 + gmpy2.mpfr('1.0')
  mpfr('2.0')

(ditto mpmath)

> - it seems rather likely that any attempt to combine a float and
> a Decimal instance in this way is a bug, or at least something that
> hasn't been fully thought through by the developer, so we
> force the developer to make an explicit conversion

Maybe it's ok for base-2 multiprecision arithmetics, as in the
example above.

Maybe not.  But in this case, if interoperability with float's (or any other
implementation for numbers.Real) is a requirement for any
numbers.Real-derived class - that should be documented.  Perhaps, then
there are bugs in mpmath/gmp2, which do claim they implement Real type:
i.e. either they should't implement automatic conversion or don't claim
they do implement numbers.Real.

> For historical discussions, see #1682.

Thank you, I'll look into.

--

___
Python tracker 

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

[issue32592] Drop support of Windows Vista and Windows 7

2021-03-23 Thread Mitja kocjančič


Mitja kocjančič  added the comment:

doh, thats unfortunate I was too late to complain, and now its all gone
oh well, I guess people will not roll back commits now, I hoped windows 7 
supported could be kept at least til python4 (or when microsoft completly 
abandons  win7 (when the API will change as well, just like with python3 there 
was python2.7 which was like a LST release for ubuntu)

--

___
Python tracker 

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

[issue43511] tkinter with Tk 8.6.11 is slow on macOS

2021-03-23 Thread Thomas Wamm



Thomas Wamm  added the comment:

Failed tkinter tests were already noted in Issue 42507.
No mention of failures correlating with much slower testing.

--

___
Python tracker 

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

[issue43511] tkinter with Tk 8.6.11 is slow on macOS

2021-03-23 Thread Thomas Wamm

Thomas Wamm added the comment:

Summary: "poor tkinter performance correlates with failed self-tests"

I'm an amateur hobbyist noobie programmer, so sophisticated testing is a
challenge for me. I raised this issue because I noticed Python graphics thru
tkinter is especially slow on MacOS, and especially ultra-slow on my new M1 Mac
Mini with Python 3.9.2 or 3.10.0a6 for Apple silicon. Aside from this weird
issue, the M1 Mac outperforms all my other computers (including Win10 on
i5-9500T, and Raspberry Pi 400). I'm expecting at least 10x performance
improvement on M1 Macs when this issue gets resolved.

Anyway, I looked under the hood. I found some tkinter test programs runnable
on MacOS with:

/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/tkinter/test/runtktests.py

The same program is buried in the Windows Python modules library, but was not
findable in Python 3.7.3 for Linux on Raspberry Pi.

So I ran runtktests.py on Windows 10 and MacOS in many configurations. All was
good EXCEPT Python 3.9.2 and 3.10.0a6 on old MacOS 10.11.6 and new MacOS
11.2.3. Those configs report about 10 Failed tests in a suite of over 1000
tests, and interestingly the 3.9 and 3.10 tests run about 4x slower than the
older Python 3.8 tests that reported zero failures.

So poor tkinter performance on MacOS correlates with failed tkinter self-tests.
Maybe a more expert person could dig deeper?

___
Python tracker

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

[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)



Christian Heimes  added the comment:

The __getattr__ hack is not needed. You can reset the flags in a different, 
more straight forward way:


class ReproducibleZipInfo(ZipInfo):
__slots__ = ()

def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self._reset_flags()

@classmethod
def from_file(cls, *args, **kwargs):
zinfo = super().from_file(*args, **kwargs)
zinfo._reset_flags()
return zinfo

def _reset_flags(self):
self.date_time = (1980, 0, 0, 0, 0, 0)
self.create_system = 0
self.external_attr = 0


>>> zinfo = ReproducibleZipInfo.from_file("/etc/os-release")
>>> zinfo.external_attr
0
>>> zinfo.create_system
0
>>> zinfo.date_time
(1980, 0, 0, 0, 0, 0)


I think it makes also sense to replace hard-coded ZipInfo class with dispatcher 
attribute on the class:


@@ -1203,6 +1211,7 @@ class ZipFile:
 
 fp = None   # Set here since __del__ checks it
 _windows_illegal_name_trans_table = None
+zipinfo_class = ZipInfo
 
 def __init__(self, file, mode="r", compression=ZIP_STORED, allowZip64=True,
  compresslevel=None, *, strict_timestamps=True):
@@ -1362,7 +1371,7 @@ def _RealGetContents(self):
 # Historical ZIP filename encoding
 filename = filename.decode('cp437')
 # Create ZipInfo instance to store file information
-x = ZipInfo(filename)
+x = self.zipinfo_class(filename)

--

___
Python tracker 

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

[issue43601] Tools/c-analyzer/check-c-globals.py run throw exception err

2021-03-23 Thread junyixie



junyixie  added the comment:

found in must-reslove.sh
function run_capi() {
./python Tools/c-analyzer/c-analyzer.py capi \
--no-progress \
--group-by kind \
--func --inline --macro \
--no-show-empty \
--ignore '' \
$@
}

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

[issue43602] Include Decimal's in numbers.Real

2021-03-23 Thread Mark Dickinson



Mark Dickinson  added the comment:

> I assume, the reason is: there is no lossless conversion to float's (and vice 
> verse).

No, I don't think that's the reason (and in fact we _do_ have lossless 
conversion of floats to Decimal instances). IMO, the reasons are:

- it's not obvious what the *type* of the result of some_float + 
some_other_decimal should be, and

- it seems rather likely that any attempt to combine a float and a Decimal 
instance in this way is a bug, or at least something that hasn't been fully 
thought through by the developer, so we force the developer to make an explicit 
conversion

For historical discussions, see #1682.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue43466] ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs



Christian Heimes  added the comment:

GH-24989 adds -Wl,--exclude-libs just for libssl.a and libcrypto.a IFF support 
for -Wl,--exclude-libs,ALL is detected by configure. This puts the symbols from 
the OpenSSL archive files into the LOCAL segment of ELF binaries. The PR does 
not set -Wl,--exclude-libs,ALL because I like to keep behavior the same as with 
3.9.

When OpenSSL is locally build with "no-shared -fPIC", then Python automatically 
builds a partially static-linked _ssl and _hashlib extension modules that do 
not pollute the global namespace:


$ ./config \
--prefix=/home/heimes/dev/python/multissl/openssl/1.1.1j-static \
--openssldir=/etc/pki/tls \
no-shared -fPIC
...
$ ./configure 
--with-openssl=/home/heimes/dev/python/multissl/openssl/1.1.1j-static
$ make
$ ldd build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so 
linux-vdso.so.1 (0x7fff8dbbc000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fa5a533d000)
libc.so.6 => /lib64/libc.so.6 (0x7fa5a5172000)
/lib64/ld-linux-x86-64.so.2 (0x7fa5a56ac000)
$ readelf -Ws build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so 
| grep SSL_CTX_new
  5617: 00072a90  1133 FUNCLOCAL  DEFAULT   11 SSL_CTX_new


I deliberately did not update documentation with instructions for static 
linking. Static linking of OpenSSL has security and compatibility implications. 
I don't want to officially support it and deal with bug reports. 
-Wl,--exclude-libs just enables sane partial static-linking.

--

___
Python tracker 

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

[issue43466] ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs



Change by Christian Heimes :


--
pull_requests: +23748
pull_request: https://github.com/python/cpython/pull/24989

___
Python tracker 

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

[issue32592] Drop support of Windows Vista and Windows 7

2021-03-23 Thread Alexey Izbyshev



Alexey Izbyshev  added the comment:

As far as I understand, commit [1] explicitly prevents CPython from running on 
Windows 7, and it's included into 3.9. So it seems to be too late to complain, 
despite that, according to Wikipedia, more than 15% of all Windows PCs are 
still running Windows 7 [2].

[1] 
https://github.com/izbyshev/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5
[2] https://en.wikipedia.org/wiki/Windows_7

--

___
Python tracker 

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

[issue32592] Drop support of Windows Vista and Windows 7

2021-03-23 Thread Mitja kocjančič


Mitja kocjančič  added the comment:

I have to agree with msg389225, I use windows 7 on my dev machine as well as I 
use some programs and devices that unfortionatly do not work on windows 10 so 
update is not possible, now it would be realy anoying that I would loose python 
support as well since I use one device with python that does not work on win10

so I am in favour that python keeps the workarounds and fallback code for 
Windows 7 at least until ESU supports ends (since if its a dead code why would 
you remove it just leave it in, if it works well and you don't touch it often 
it does no harm)

--
nosy: +veso266

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real



Sergey B Kirpichev  added the comment:

> Operations between decimals and floats raise a TypeError.

I saw this)  And as I said, I assume, the reason is: there is no lossless 
conversion to float's (and vice verse).

If so (point 2), neither multiple-precision type (e.g. gmpy2.mpfr) can subclass 
from the numbers.Real (there can be different precisions, different bases) and 
that sounds too restrictive.

>From the mathematician point of view, both built-in float's and Decimal's 
>could be viewed as (inexact!) representations for real numbers.  But if _any_ 
>such representations, conforming the numbers abc must be lossless converted to 
>each other - that might be a documentation issue.

> P.S.  With respect to #4, we've harmonized the APIs as much as we sensibly 
> can.

That was very minor, yes.  Something like try-except could be used here, trying 
as_integer_ratio().

--

___
Python tracker 

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

[issue41064] Specialise syntax error of **dict in f-string field

2021-03-23 Thread Eric V. Smith



Eric V. Smith  added the comment:

The parens are added in fstring_compile_expr at 
https://github.com/python/cpython/blob/9feae41c4f04ca27fd2c865807a5caeb50bf4fc4/Parser/string_parser.c#L391

I don't recall if this is really only a "skip leading whitespace" problem, or 
if there's some other reason they're required. If it's just a whitespace issue, 
maybe skipping leading whitespace in fstring_compile_expr is a better idea? One 
of the reasons I originally didn't want to skip leading whitespace is because I 
didn't want to add yet another place where we'd have to maintain a "what 
qualifies as whitespace to the compiler?" decision.

--

___
Python tracker 

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

[issue43601] Tools/c-analyzer/check-c-globals.py run throw exception err

2021-03-23 Thread Ammar Askar



Change by Ammar Askar :


--
nosy: +eric.snow

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real



Change by Raymond Hettinger :


--
Removed message: https://bugs.python.org/msg389373

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real



Raymond Hettinger  added the comment:

We don't have a choice here.  Operations between decimals and floats raise a 
TypeError.  So, we can't register Decimal as a Real; otherwise, static type 
checking wouldn't be able to flag the following as invalid:

def add(a: Real, b: Real) -> Real:
return a + b

a: Real = Decimal('1.1')
b: Real = 2.2
print(add(a, b))

This gives:

Traceback (most recent call last):
  File "/Users/raymond/Documents/tmp.py", line 10, in 
print(add(a, b))
  File "/Users/raymond/Documents/tmp.py", line 6, in add
return a + b
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

Almost the whole point of static checking is early detection of these problems 
so we won't encounter the TypeError at runtime.

P.S.  With respect to #4, we've harmonized the APIs as much as we sensibly can. 
 That allows some code to be more polymorphic as long at the type is consistent 
throughout.  That is much different than freely mixing floats and decimals in 
the direct interactions.

--

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real



Raymond Hettinger  added the comment:

We don't have a choice here.  Operations between decimals and floats raise a 
TypeError.  So, we can't register Decimal as a Real; otherwise, static type 
checking wouldn't be able to flag the following as invalid:

def add(a: Real, b: Real) -> Real:
return a + b

a: Real = Decimal('1.1')
b: Real = 2.2
print(add(a, b))

This gives:

Traceback (most recent call last):
  File "/Users/raymond/Documents/tmp.py", line 10, in 
print(add(a, b))
  File "/Users/raymond/Documents/tmp.py", line 6, in add
return a + b
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'

Almost the whole point of static checking is to avoid these TypeErrors at 
runtime

--
nosy: +rhettinger

___
Python tracker 

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

[issue43602] Include Decimal's in numbers.Real