date:20210412



Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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

[issue43826] Resource warnings in test_subprocess


New submission from Karthikeyan Singaravelan :

It seems that some of the pipe objects were not closed properly causing 
resource warnings. Regarding "subprocess still running warning" I guess we need 
to call kill() on the subprocess before exiting test_send_signal_race2. I will 
raise a PR for this.

➜  cpython git:(master) ./python -X dev -Wall -m test test_subprocess   

0:00:00 load avg: 0.06 Run tests sequentially
0:00:00 load avg: 0.06 [1/1] test_subprocess
/root/cpython/Lib/subprocess.py:1066: ResourceWarning: subprocess 22107 is 
still running
  _warn("subprocess %s is still running" % self.pid,
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=5>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/root/cpython/Lib/unittest/case.py:549: ResourceWarning: unclosed file 
<_io.BufferedReader name=7>
  method()
ResourceWarning: Enable tracemalloc to get the object allocation traceback

== Tests result: SUCCESS ==

1 test OK.

Total duration: 28.9 sec
Tests result: SUCCESS

--
components: Tests
messages: 390924
nosy: giampaolo.rodola, gregory.p.smith, xtreak
priority: normal
severity: normal
status: open
title: Resource warnings in test_subprocess
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

[issue43825] Deprecation warnings in test cases



Change by Karthikeyan Singaravelan :


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

___
Python tracker 

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

[issue43825] Deprecation warnings in test cases



New submission from Karthikeyan Singaravelan :

Following deprecation warnings are raised when tests are ran with -Wall in 
CPython test suite. I will raise a PR for this.


0:03:48 load avg: 0.79 [ 59/427] test_cmd_line  


/root/cpython/Lib/test/test_cmd_line.py:865: DeprecationWarning: invalid escape 
sequence \u 

  self.check_string(b"'\u1f'")

0:04:11 load avg: 0.86 [ 77/427] test_collections   


/root/cpython/Lib/test/test_collections.py:1518: DeprecationWarning: Please use 
assertEqual instead.

  self.assertEquals(len(s), len(items) - 1)

--
components: Tests
messages: 390923
nosy: xtreak
priority: normal
severity: normal
status: open
title: Deprecation warnings in test cases
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

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

2021-04-12 Thread Jordan Borean



Jordan Borean  added the comment:

I'm looking through the PR https://github.com/python/cpython/pull/17975 and it 
doesn't look like it addresses this particular problem. The code for start_tls 
https://github.com/python/cpython/blob/d2a8e69c2c605fbaa3656a5f99aa8d295f74c80e/Lib/asyncio/base_events.py#L1210-L1212
 has a check for the attribute '_start_tls_compatible' but 
_SSLProtocolTransport 
(https://github.com/python/cpython/blob/master/Lib/asyncio/sslproto.py) does 
not set this. The PR mentioned https://github.com/python/cpython/pull/17975 
does not seem to touch any of this so I would assume the problem is still there?

I also installed 3.10.0a7 and this problem still persists when I call 
loop.start_tls with my SSL writer transport.

--
nosy: +jborean93

___
Python tracker 

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

[issue43787] Optimize BZ2File, GzipFile, and LZMAFile iter method.

2021-04-12 Thread Inada Naoki



Inada Naoki  added the comment:


New changeset d2a8e69c2c605fbaa3656a5f99aa8d295f74c80e by Inada Naoki in branch 
'master':
bpo-43787: Add __iter__ to GzipFile, BZ2File, and LZMAFile (GH-25353)
https://github.com/python/cpython/commit/d2a8e69c2c605fbaa3656a5f99aa8d295f74c80e


--

___
Python tracker 

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

[issue43787] Optimize BZ2File, GzipFile, and LZMAFile iter method.

2021-04-12 Thread Inada Naoki



Change by Inada Naoki :


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

[issue43824] array.array.deepcopy() accepts a parameter of any type

2021-04-12 Thread Josh Rosenberg



Josh Rosenberg  added the comment:

__deepcopy__ is required to take a second argument by the rules of the copy 
module; the second argument is supposed to be a memo dictionary, but there's no 
reason to use it for array.array (it can't contain Python objects, and you only 
use the memo dictionary when recursing to Python objects you contain).

Sure, the second argument isn't being type-checked, but it's not used at all, 
and it's only supposed to be invoked indirectly via copy.deepcopy (that passes 
a dict).

Can you explain what is wrong here that needs to be fixed? Seems like a 
straightforward "protocol requires argument, but use case doesn't have anything 
to do with it, so it ignores it". Are you suggesting adding type-checks for 
something that never gets used?

--
nosy: +josh.r

___
Python tracker 

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

[issue41515] typing.get_type_hints generates KeyError



Karthikeyan Singaravelan  added the comment:

Thanks Victor. I have created https://github.com/python/cpython/pull/25379 that 
uses self.assertEqual instead of assert that produces syntax warning.

--

___
Python tracker 

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

[issue41515] typing.get_type_hints generates KeyError



Change by Karthikeyan Singaravelan :


--
pull_requests: +24111
pull_request: https://github.com/python/cpython/pull/25379

___
Python tracker 

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

[issue43824] array.array.deepcopy() accepts a parameter of any type

2021-04-12 Thread MingZhe Hu



New submission from MingZhe Hu :

The C implementation of foreign function array.array.__deepcopy__() is declared 
as follows:

https://github.com/python/cpython/blob/d9151cb45371836d39b6d53afb50c5bcd353c661/Modules/arraymodule.c#L855

The second argument is unused in the function body.

However, corresponding PyMethodDef is declared with `METH_O` flag, meaning one 
parameter should be passed to array.array.__deepcopy__() from the Python side:

https://github.com/python/cpython/blob/d9151cb45371836d39b6d53afb50c5bcd353c661/Modules/clinic/arraymodule.c.h#L30

This makes the following code legal:

```
import array
a = array.array('b',  [ord('g')])
a.__deepcopy__('str')
a.__deepcopy__(1)
a.__deepcopy__([1,'str'])
```

A parameter of ANY type can be passed to the foreign function, without effect 
on its semantic.

These code are clinic generated, and similar problems can be found for more 
foreign functions.

--
components: Argument Clinic, Extension Modules
messages: 390918
nosy: Elaphurus, larry
priority: normal
severity: normal
status: open
title: array.array.__deepcopy__() accepts a parameter of any type
type: behavior
versions: Python 3.10, Python 3.6, 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

[issue43823] Improve syntax errors for invalid dictionary literals



Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue43823] Improve syntax errors for invalid dictionary literals



New submission from Pablo Galindo Salgado :

Currently the error for invalid dict literals is generic:

>>> {1:2, 3:}
  File "", line 1
{1:2, 3:}
^
SyntaxError: invalid syntax
>>> {1:2, 3}
  File "", line 1
{1:2, 3}
   ^
SyntaxError: invalid syntax

We can have better errors for these cases, which can help with big dict 
literals:

>>> {1:2, 3}
  File "", line 1
{1:2, 3}
   ^
SyntaxError: ':' expected after dictionary key
>>> {1:2, 3:}
  File "", line 1
{1:2, 3:}
   ^
SyntaxError: expression expected after dictionary key and ':'

--
messages: 390917
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax errors for invalid dictionary literals

___
Python tracker 

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

[issue43822] Improve syntax errors for missing commas



Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue43822] Improve syntax errors for missing commas



New submission from Pablo Galindo Salgado :

Given that is quite common to forgot a comma in containers, function calls, 
...etc and that the current error is:

>>> [a, b, c d]
  File "", line 1
[a, b, c d]
 ^
SyntaxError: invalid syntax

We could improve the user experience quite a lot if we mention that probably 
the user forgot a comma:

>>> [a, b, c d]
  File "", line 1
[a, b, c d]
 ^
SyntaxError: invalid syntax. Perhaps you forgot a comma?

--
messages: 390916
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Improve syntax errors for missing commas

___
Python tracker 

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

[issue40006] enum: Add documentation for _create_pseudo_member_ and composite members



Ethan Furman  added the comment:

`_create_pseudo_member_` was an implementation detail and has been removed.  I 
did update the doc string which was migrated to `_missing_`.

--

___
Python tracker 

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

[issue40006] enum: Add documentation for _create_pseudo_member_ and composite members



Change by Ethan Furman :


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

___
Python tracker 

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

[issue43797] Improve syntax error for invalid comparisons



Change by Pablo Galindo Salgado :


--
pull_requests: +24107
pull_request: https://github.com/python/cpython/pull/25375

___
Python tracker 

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

[issue43770] Rework C types initialization



Change by STINNER Victor :


--
pull_requests: +24106
pull_request: https://github.com/python/cpython/pull/25373

___
Python tracker 

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

[issue43817] Add typing.get_annotations()

2021-04-12 Thread Jelle Zijlstra



Change by Jelle Zijlstra :


--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue43821] Undocumented behavior of sleep functions and asyncio delayed execution

2021-04-12 Thread Josef Havránek


New submission from Josef Havránek :

Hi i found undocumented behavior of time.sleep, and call_at / call_later from 
asyncio loop


There are two things to properly document/consider.
It is time of delay/sleep when time for python stops  (aka computer is going to 
hibernate/Cpu not runing) because time is relative from view of RTC(real time 
clock) and program both is correct 

curent behavior on
Python 3.9.4 (tags/v3.9.4:1f2e308, Apr  6 2021, 13:40:21) [MSC v.1928 64 bit 
(AMD64)] on win32

There is  time.sleep , asyncio.sleep and call_later 
They stall for time that has pased for program not on RTC (so it may take time) 
they not resume when time already passed in real word

then there is loop.call_at

there in in doc  two kinda contradicadictory statements.
and that is 
"This method’s behavior is the same as call_later()"

"and Schedule callback to be called at the given absolute timestamp when (an 
int or a float), using the same time reference as loop.time()."

thing is it should be legal acording to 1st qoute use
loop.call_at(seconds_to_sleep, lambda:print("something usefull")

but acording to 2nd we should use 
loop.call_at(seconds_to_sleep+loop.time(), lambda:print("something usefull")

and They Both execute after seconds_to_sleep! this is a bug because time to 
sleep cant be bigger than curent loop.time() then it would execute at incorect 
time.


Also there is second bug
loop.call_at(seconds_to_sleep+loop.time(), lambda:print("something usefull")

Even this is acording to me(how i understood from doc correct usage)
This will efectively behave as call_later because it will not call callback 
when seconds_to_sleep already passed since submission

however using
loop.call_at(seconds_to_sleep, lambda:print("something usefull")
will invoke as soon as program resumed from hybernation/when missed

i think loop.call_at(seconds_to_sleep, lambda:print("something usefull") should 
not wait seconds_to_sleep when it is smaller then loop.time() and just execute 
it

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 390914
nosy: Josef Havránek, docs@python
priority: normal
severity: normal
status: open
title: Undocumented behavior of sleep functions and asyncio delayed execution
type: behavior
versions: Python 3.10, Python 3.6, 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

[issue43820] Remove namespace copy from dataclasses.make_dataclass()



Change by Eric V. Smith :


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

___
Python tracker 

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

[issue42248] Raised exception in Enum keeping user objects alive unnecessarily



Ethan Furman  added the comment:


New changeset 6379924ecd51e346b42b0293da0f4442a0f67707 by Ethan Furman in 
branch '3.9':
[3.9] bpo-42248: [Enum] ensure exceptions raised in ``_missing_`` are released 
(GH-25350). (GH-25370)
https://github.com/python/cpython/commit/6379924ecd51e346b42b0293da0f4442a0f67707


--

___
Python tracker 

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

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

2021-04-12 Thread Eryk Sun



Eryk Sun  added the comment:

> If that's the problem then why not change all of them to use the 
> name "address" or "addr" to avoid confusion and make it clear 
> simple. What is your view?

Change them all to refer to `ptr`. It's not worth introducing a breaking change:

>>> ctypes.string_at(ptr=b'spam')
b'spam'

--

___
Python tracker 

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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-12 Thread Eryk Sun



Eryk Sun  added the comment:

> So we stop passing the O_TEMPORARY flag. If __enter__() is called, 
> close() closes the file but doesn't delete anything, and 
> __exit__() closes the file (if open) and deletes it (even if it 
> wasn't open). If there is no __enter__(), close() also deletes the 
> file.

This behavior change is fine if O_TEMPORARY isn't used. I wasn't disagreeing 
with Ethan. I was providing a summary of a common use case that conflicts with 
using O_TEMPORARY to make it clear that this flag has to be omitted if we're 
not implementing something like a delete_on_close boolean option.

Most of my last comment, however, was dedicated to implementing TemporaryFile() 
if this change is applied, instead of leaving it as an alias for 
NamedTemporaryFile(). I can't imagine not wanting the guaranteed cleanup 
semantics of O_TEMPORARY in the case of an anonymous temporary file that 
doesn't need to be reopened. I also want O_SHORT_LIVED. This opens the file 
with the attribute FILE_ATTRIBUTE_TEMPORARY [1], which tells the cache manager 
to try to keep the file contents in memory instead of flushing data to disk.

---

[1] 
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#caching_behavior

--

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



STINNER Victor  added the comment:

See https://github.com/python/cpython/blob/master/Include/README.rst for the 
organization of the C API.

--

___
Python tracker 

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

[issue43774] [Doc] Document configure options in the Python documentation



STINNER Victor  added the comment:


New changeset 85918e4ab6e9410008aef6dedf000d24b3e120ea by Victor Stinner in 
branch 'master':
bpo-43774: Add more links to configure options (GH-25363)
https://github.com/python/cpython/commit/85918e4ab6e9410008aef6dedf000d24b3e120ea


--

___
Python tracker 

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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows



Ethan Furman  added the comment:

Hey, you agree with me now, so it's not noise.  ;-)

--

___
Python tracker 

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

[issue43820] Remove namespace copy from dataclasses.make_dataclass()



New submission from Eric V. Smith :

In make_dataclasses(), the "namespace" argument is copied because it is 
mutated. This isn't really necessary: the callback passed to types.new_class() 
could just update its "ns" parameter with "namespace" and with the new 
attributes (__anotations__ and default field values).

This would eliminate the need to copy "namespace".

--
assignee: eric.smith
components: Library (Lib)
messages: 390907
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Remove namespace copy from dataclasses.make_dataclass()
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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-12 Thread Paul Moore



Paul Moore  added the comment:

Sorry - I'm maybe making an unwarranted assumption. If simply removing "delete 
on close" behaviour in the CM case is acceptable, then I'm 100% in favour of 
that.

I'd assumed that it was somehow unacceptable, but you're right, and it's not 
clear if Eryk is agreeing or disagreeing with you (I assumed he was 
disagreeing, based mainly on the length and complexity of his response :-)) It 
didn't help that somehow Steve's reply wasn't visible when I posted mine.

Apologies for the noise.

--

___
Python tracker 

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

[issue43819] ExtensionFileLoader Does Not Implement invalidate_caches

2021-04-12 Thread Ian H

New submission from Ian H :

Currently there's no easy way to get at the internal cache of module spec
objects for compiled extension modules. See
https://github.com/python/cpython/blob/20ac34772aa9805ccbf082e700f2b033291ff5d2/Python/import.c#L401-L415.
For example, these module spec objects continue to be cached even if we call
importlib.invalidate_caches. ExtensionFileLoader doesn't implement the
corresponding method for this.

The comment in the C file referenced above implies this is done this way to
avoid re-initializing extension modules. I'm not sure if this can be fixed, but
I figured I'd ask for input. Our use-case is an academic project where we've
been experimenting with building an interface for linker namespaces into Python
to allow for (among other things) loading multiple copies of any module without
explicit support from that module. We've been able to do this without having
custom builds of Python. We've instead gone the route of overriding some of the
import machinery at runtime. To make this work we need a way to prevent caching
of previous import-related information about a specific extension module. We
currently have to rely on an unfortunate hack to get access to the internal
cache of module spec objects for extension modules and modify that dictionary
manually. What we have works, but any sort of alternative would be welcome.

--
messages: 390905
nosy: Ian.H
priority: normal
severity: normal
status: open
title: ExtensionFileLoader Does Not Implement invalidate_caches
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

[issue42238] Deprecate suspicious.py?



Pablo Galindo Salgado  added the comment:

Background on why I reactivated it:

I every single alpha release I had to fix actual documentation errors (no false 
positives) like the one fixed here:

https://github.com/python/cpython/commit/20ac34772aa9805ccbf082e700f2b033291ff5d2

I don't like the check, but the release management team don't like to have to 
restart the release process just fo fix a bunch of docs issues that should have 
been detected by the CI.

If we remove the fix, we need to coordinate all together because currently the 
status quo is that the RM team now is responsable of fixing the documentation 
errors as there are several release tools (and other ones) that depend on this 
target passing.

--

___
Python tracker 

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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows



Ethan Furman  added the comment:

Paul,

If "rescuing"  (i.e. "fixing" ;) NamedTemporaryFile was arduous, complicated, 
or had serious backwards-compatibility issues then I would completely agree 
with you.  However, the fix is simple, the only backwards-compatible issue is 
the file would still be there /while a context manager was in use/ after it had 
been closed (which conforms to most, if not all, users of context managers) and 
a file would be left on disk in the event of a hard crash (hopefully a rare 
occurrence).

Your proposal, on the other, is a lot of work.  Is the minor backwards 
compatibility worth all that work?

--

___
Python tracker 

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

[issue43798] Add position metadata to alias AST type



Pablo Galindo Salgado  added the comment:

Ah, it was not clear from the issue that pytest was constructing nodes by hand. 
It makes sense now. Thanks!

--

___
Python tracker 

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

[issue43798] Add position metadata to alias AST type

2021-04-12 Thread daniel hahler



Change by daniel hahler :


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

[issue43798] Add position metadata to alias AST type

2021-04-12 Thread daniel hahler



daniel hahler  added the comment:

@Pablo: the problem (referenced in the pytest issue) is that `ast.alias` has 
new required arguments now (see also the adjusted test in
https://github.com/python/cpython/commit/75a06f067bd0a2687312e5f8e78f9075be76ad3a#diff-3f516b60719dd445d33225e4f316b36e85c9c51a843a0147349d11a005c55937R1060-R1061).
  That's expected/wanted though (assuming that it should not have "defaults" 
for B/C), and there's a patch for the issue at 
https://github.com/pytest-dev/pytest/pull/8540.

--
nosy: +blueyed

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Andrew V. Jones  added the comment:

> I think the fact that they've been moved to Include/cpython means that user
> code shouldn't be using them.
>

I think it is fine to say that they shouldn't be used, but then we get this 
from Victor's blog:

> It was decided that internal header files must not be included implicitly by
> the generic #include , but included explicitly. 
>

So, is it the case that we have two issues here:

1) Cython is using stuff it shouldn't (I can do a PR against Cython)

2) Python.h is exposing more than it should (so, if Python "core" wants 
something from pyctype.h, it should be explicitly including pyctype.h and not 
getting via Python.h)

?

--

___
Python tracker 

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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

2021-04-12 Thread Paul Moore



Paul Moore  added the comment:

There's a lot of technical discussion of implementation details here, but not 
much about use cases. IMO, what's more important is whether NamedTemporaryFile 
is *useful* to people, and what they want to use it *for*. Working out how to 
implement it can come after we know what people want it to do.

My particular use case is actually pretty simple, and I suspect constitutes a 
fairly major proportion of what people want of this API:

1. Create a temporary file.
2. Write some data into it.
3. At some point, we're done writing to the file.
4. Only after that point, pass the name of the file to "somewhere else" for 
processing. That's often, in my use cases, as an argument to a subprocess.
5. Once we're all done, clean up securely.

The key additional requirement is that this is done "safely" (by which I mean I 
don't have to think about race conditions, etc, as someone else has that 
covered). What I think that means is that we need to maintain an open 
filehandle of *some* sort continually, but there's a point where the user can 
say "I'm done writing, I want to share this now".

Is there an actual known use case for the behaviour of deleting the file on 
close *rather* than at the end of the CM's scope? That's unlike any other CM I 
know of, where the scope ending is what triggers tidy-up.

Maybe NamedTemporaryFile should be retained for backward compatibility, but as 
a normal function, with the CM behaviour deprecated. It would still be 
essentially useless on Windows, but we maybe don't care about that.

In addition, we create a *new* context manager, that simply creates the file at 
the start and deletes it at close of scope. It returns a writeable file object, 
but that can be closed (and the documentation notes that for portability it 
*must* be closed before passing the name to another process for use).

I don't know enough about how we protect this against race condition attacks, 
but I'm pretty sure that this API gives us the best chance we're likely to have 
of doing so in a cross-platform manner. (Maybe we have a "reopen" method rather 
than "close". Or can we open *two* file handles at the start, one for writing 
and one for reading, return the one for writing, and keep the one for reading 
internal, purely to keep the file locked? I feel like that wouldn't work 
because if *we* can open a write handle, so could an attacker - but as I say, 
I'm not an expert).

Basically, I may be wrong, but I feel that we should stop trying to "rescue" 
NamedTemporaryFile, and instead try providing an *alternative* that handles the 
cross-platform use case that started all of this.

--

___
Python tracker 

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

[issue42238] Deprecate suspicious.py?



STINNER Victor  added the comment:

Pablo reenabled the check:

commit 20ac34772aa9805ccbf082e700f2b033291ff5d2 (upstream/master, master)
Author: Pablo Galindo 
Date:   Mon Apr 12 20:53:15 2021 +0100

Fix Sphinx errors in the documentation and re-activate the suspicious check 
(GH-25368)

The suspicious check is still executed as part of the release process and 
release managers have been
lately fixing some actual errors that the suspicious target can find. For 
this reason, reactivate the suspicious
until we decide what to do in a coordinated fashion.

--
nosy: +pablogsal, vstinner

___
Python tracker 

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

[issue43818] Email does not apply policy to multipart messages with defects

2021-04-12 Thread Joseph Ishac



New submission from Joseph Ishac :

I have noticed an issue (Python 3.8.5) where an email can be read in as bytes, 
but will not be returned as such with the as_bytes() call if the message is 
multipart, has a boundary which is not properly quoted, and the message has 
non-ascii text. It seems to be a result of how multipart messages are treated 
if the NoBoundaryInMultipartDefect is encountered [See Test #1].

I would argue that attempting to output the test message in the sample script 
with an 8bit, utf-8 enabled policy should return the original bytes as the 8bit 
policy should be applied to the "body" portion (any part after the null lines) 
of the email (as would be the case if it were not multipart) [See Test #4]

Currently it appears that the entire message is treated as headers, applying 
the strict 7bit, ascii requirement to the entire contents of the message. 
Furthermore, the msg.preamble is None.

I am also uncertain that attempting to leverage the handle_defect hooks would 
be helpful as correcting the boundary doesn't seem to work unless you re-parse 
the message [See Tests #2 and #3]

So the requested change would be to apply the encoding output policy to all 
portions of a message after the null line ending the headers.

--
components: email
files: email.multipart.test.py
messages: 390897
nosy: barry, jishac, r.david.murray
priority: normal
severity: normal
status: open
title: Email does not apply policy to multipart messages with defects
versions: Python 3.8
Added file: https://bugs.python.org/file49955/email.multipart.test.py

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Eric V. Smith  added the comment:

These files were probably added as part of str.format() or short float repr. I 
think the fact that they've been moved to Include/cpython means that user code 
shouldn't be using them. See https://bugs.python.org/issue35134 and 
https://vstinner.github.io/split-include-directory-python38.html. Probably best 
to ask Victor.

--
nosy: +vstinner

___
Python tracker 

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

[issue40066] Enum: modify repr, str; update docs

2021-04-12 Thread Stefan Behnel


Stefan Behnel  added the comment:

> why /shouldn't/ we make the change?

It breaks doctests, and probably some other unit tests, too, e.g. for output 
formatting.

What should we suggest users to do? Replace

>>> get_flag(…)


by

>>> get_flag(…) == app_enums.TrickyFlag  or get_flag(…)  # (also show 
result on failure)
True

and

assertEqual(
"You caught the %s flag!" % result,
"You caught the app_enums.TrickyFlag flag!")

by

assertEqual(
("You caught the %s flag!" % result).replace("app_enums.", ""),
"You caught the TrickyFlag flag!")

?

Note that using "%r" does not help, since it's also backwards incompatible.

For their own enums, users can probably backport (or forward-port) "__str__()" 
and "__repr__()" themselves in order to work around this difference. But it's 
something they would have to do.

I certainly understand the reasoning, and it also makes new Py3.10-only 
doctests nicer, actually, but IMHO it counts as deliberate breakage.

--
nosy: +scoder

___
Python tracker 

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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows



Steve Dower  added the comment:

O_TEMPORARY is clearly not the right option here, and we should just move the 
unlink call into __exit__ and attempt it even if close() has been called.

Windows's "delete on close" functionality is great, but if you haven't designed 
for its semantics, it's unusable. And this library is not designed for it, so 
users can't rely on the native functionality.

So we stop passing the O_TEMPORARY flag. If __enter__() is called, close() 
closes the file but doesn't delete anything, and __exit__() closes the file (if 
open) and deletes it (even if it wasn't open). If there is no __enter__(), 
close() also deletes the file.

--

___
Python tracker 

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

[issue41515] typing.get_type_hints generates KeyError



STINNER Victor  added the comment:

> Thanks -- odd this didn't fail in CI.

The CI runs tests with "make buildbottest" which uses the -w option:

  -w, --verbose2re-run failed tests in verbose mode

When test___all__ is re-run in verbose mode, it doesn't fail:

"== Tests result: FAILURE then SUCCESS =="

--

___
Python tracker 

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

[issue41515] typing.get_type_hints generates KeyError



Guido van Rossum  added the comment:

Thanks -- odd this didn't fail in CI. We'll get it fixed.

--

___
Python tracker 

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

[issue41515] typing.get_type_hints generates KeyError



STINNER Victor  added the comment:

This change introduced a regression:
https://buildbot.python.org/all/#/builders/96/builds/1012

$ ./python -m test test___all__
0:00:00 load avg: 0.28 Run tests sequentially
0:00:00 load avg: 0.28 [1/1] test___all__
test test___all__ failed -- Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/test/test___all__.py", line 104, in 
test_all
self.check_all(modname)
  File "/home/vstinner/python/master/Lib/test/test___all__.py", line 25, in 
check_all
exec("import %s" % modname, names)
  File "/home/vstinner/python/master/Lib/contextlib.py", line 140, in __exit__
next(self.gen)
  File "/home/vstinner/python/master/Lib/test/support/warnings_helper.py", line 
177, in _filterwarnings
raise AssertionError("unhandled warning %s" % reraise[0])
AssertionError: unhandled warning {message : SyntaxWarning('assertion is always 
true, perhaps remove parentheses?'), category : 'SyntaxWarning', filename : 
'/home/vstinner/python/master/Lib/test/test_typing.py', lineno : 2275, line : 
None}

test___all__ failed

== Tests result: FAILURE ==

1 test failed:
test___all__

Total duration: 2.7 sec
Tests result: FAILURE


It comes from the following line of test_bad_module() in Lib/test/test_typing:

assert(get_type_hints(BadModule), {})

assert should be used as "assert test" or "assert test, expr". assert (expr, 
expr) tests if the tuple (2 items) is true, and it's always true.

--
nosy: +vstinner

___
Python tracker 

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

[issue30528] ipaddress.IPv{4,6}Network.reverse_pointer is broken

2021-04-12 Thread Roundup Robot



Change by Roundup Robot :


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

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table

2021-04-12 Thread Stefan Behnel



Stefan Behnel  added the comment:

These macros are a sort-of documented part of the C-API. At least, they were 
mentioned in a What's New document:

https://docs.python.org/3/whatsnew/2.7.html?highlight=py_isspace#build-and-c-api-changes

They were added here, for the Py2.7 release:

https://github.com/python/cpython/commit/8374981fb4d781d5ddbca313656bd3f32b49cef4

It looks to me like the header file should use "extern C".
@Eric, do you agree?

--
nosy: +eric.smith, scoder
type:  -> compile error
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

[issue42248] Raised exception in Enum keeping user objects alive unnecessarily



Ethan Furman  added the comment:


New changeset f396a1a940f8608a4be2a9ac4ef82e37c198ecd3 by Ethan Furman in 
branch '3.8':
[3.8] bpo-42248: [Enum] ensure exceptions raised in ``_missing_`` are released 
(GH-25350). (GH-25369)
https://github.com/python/cpython/commit/f396a1a940f8608a4be2a9ac4ef82e37c198ecd3


--

___
Python tracker 

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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows



Ethan Furman  added the comment:

Eryk, I'm not sure if you are agreeing or disagreeing with me. :)

On Windows it sounds like O_TEMPORARY buys us guaranteed file deletion, but 
costs us easy sharing of file resources and a difference in semantics between 
Windows and non-Windows.

Is the automatic deletion truly that valuable?

--

___
Python tracker 

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

[issue43812] Tuple unpacking in getitem



Pablo Galindo Salgado  added the comment:

I am closing this as duplicate of https://www.python.org/dev/peps/pep-0646, but 
feel free to reopen if you think there is some missing considerations.

--
resolution:  -> duplicate
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

[issue43812] Tuple unpacking in getitem



Pablo Galindo Salgado  added the comment:

This is currently being proposed as part of 
https://www.python.org/dev/peps/pep-0646.

--
nosy: +pablogsal

___
Python tracker 

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

[issue42248] Raised exception in Enum keeping user objects alive unnecessarily



Change by Ethan Furman :


--
pull_requests: +24103
pull_request: https://github.com/python/cpython/pull/25370

___
Python tracker 

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

[issue42248] Raised exception in Enum keeping user objects alive unnecessarily



Change by Ethan Furman :


--
pull_requests: +24102
pull_request: https://github.com/python/cpython/pull/25369

___
Python tracker 

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

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

2021-04-12 Thread Shreyan Avigyan



Shreyan Avigyan  added the comment:

Yeah, you're right and also it is true that changing the docstring to "ptr" can 
succinctly say "Return the byte string at void *ptr." But it's a kind of 
problem if different argument names are used for the same argument in 
docstring, argument list and documentation. If that's the problem then why not 
change all of them to use the name "address" or "addr" to avoid confusion and 
make it clear simple. What is your view?

--

___
Python tracker 

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

[issue30528] ipaddress.IPv{4,6}Network.reverse_pointer is broken

2021-04-12 Thread jana



jana  added the comment:

This code does the trick:

ipn = ipaddress.ip_network("2a0c:ac10::/32")
prefix = ipn.prefixlen
if ipn.version == 6:
rest = int((ipn.max_prefixlen - prefix) / 4)
elif ipn.version == 4:
rest = int((ipn.max_prefixlen - prefix) / 8)
return ipn.network_address.reverse_pointer.split(".", rest)[-1]

--

___
Python tracker 

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

[issue43804] Add more info about building C/C++ Extensions on Windows using MSVC

2021-04-12 Thread Shreyan Avigyan



Shreyan Avigyan  added the comment:

Kindly have a review of my PR.

--

___
Python tracker 

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

[issue43817] Add typing.get_annotations()



Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue41515] typing.get_type_hints generates KeyError



Guido van Rossum  added the comment:


New changeset a9cf69df2e031d6157f01289f66ca9cf723ceb5c by Karthikeyan 
Singaravelan in branch 'master':
bpo-41515: Fix KeyError raised in get_type_hints (GH-25352)
https://github.com/python/cpython/commit/a9cf69df2e031d6157f01289f66ca9cf723ceb5c


--

___
Python tracker 

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

[issue43817] Add typing.get_annotations()



Larry Hastings  added the comment:

> I'd say just submit the PR. Shouldn't be problematic.

Okey-doke, I can do it.  Though I have plenty to do at the moment, though, so 
it wouldn't be this week.

Is there anybody who would *enjoy* taking this on, who we could farm it out to? 
 If not, that's no problem, I should be able to get it done before 3.10b1.


> (Have you decided what to do if the eval() fails?)

My experience is that typing.get_type_hints() doesn't catch exceptions, e.g. 
NameError.  I assumed that typing.get_annotations() should behave the same way.

--

___
Python tracker 

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

[issue30528] ipaddress.IPv{4,6}Network.reverse_pointer is broken

2021-04-12 Thread jana



jana  added the comment:

Running into the same problem here. Within the zonefile rfc1035 defines a 
usecase for ipv4, but I can't find anything similar for IPv6. The feature is 
also rather obscure. The zone however is used in the zonefile as origin and in 
bind in the named.conf to refer to which zone is managed where. 

For this you want to provide the reverse network address, minus the irrelevant 
zeros, so 192.168.0.0/24 => 0.168.192.in-addr.arpa and 2001:db8::/32 => 
8.b.d.0.1.0.0.2.ip6.arpa

This would be to me a fitting and convenient interpretation of the function.

--
nosy: +jana
versions: +Python 3.7 -Python 3.5

___
Python tracker 

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

[issue43817] Add typing.get_annotations()



Guido van Rossum  added the comment:

I'd say just submit the PR. Shouldn't be problematic. (Have you decided
what to do if the eval() fails?)

--

___
Python tracker 

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

[issue43492] Upgrade to SQLite 3.35.4 in macOS and Windows

2021-04-12 Thread Erlend Egeberg Aasland



Erlend Egeberg Aasland  added the comment:

I agree, Steve.

--

___
Python tracker 

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

[issue43817] Add typing.get_annotations()



Larry Hastings  added the comment:

To be honest, I'm not 100% sure.  But I observe that typing.get_type_hints() is 
about fifty lines of code, and very few of them are the opinionated lines I 
want to avoid.

Some things typing.get_type_hints() seems to do for you:
* Work around the "classes inherit annotations" design bug.
* Unwrap wrapped functions.
* "Return empty annotations for something that _could_ have them."

--

___
Python tracker 

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

[issue43817] Add typing.get_annotations()



Guido van Rossum  added the comment:

It's fair that get_type_hints() does too much. But what does your proposed 
function do besides this?

{k: eval(v) for k, b in x.__annotations__.items()}

?

--

___
Python tracker 

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

[issue43817] Add typing.get_annotations()



Larry Hastings  added the comment:

(realized mid-issue-creation that it should have a different name)

--
title: Add typing.eval_annotations() -> Add typing.get_annotations()

___
Python tracker 

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

[issue43817] Add typing.eval_annotations()



New submission from Larry Hastings :

Currently, with PEP 563 looming over us, people who use annotations for 
something besides type hints are kind of stuck.  Converting stringized 
annotations back into useful values is a complicated problem, and there's only 
function in the standard library that will do it for you: 
typing.get_type_hints().  However, typing.get_type_hints() deals specifically 
with *type hints*.  Type hints are a subset of annotations, and they have an 
additional set of rules they want to obey.  As such typing.get_type_hints() is 
quite opinionated and makes additional changes to the annotations that someone 
who only wants to un-stringize their annotations likely does not want.

I therefore propose adding a new function to typing:

typing.get_annotations(o)

This would behave similarly to typing.get_type_hints(o), except it would be 
agnostic about the contents of the annotations.  It would simply evaluate them, 
without further changing them as typing.get_type_hints() does.  Specifically:

* It would ignore the "__no_type_check__" attribute.
* It would not wrap string annotations with ForwardRef().
* It would not wrap values with Optional[].
* It would not turn an annotation of None into type(None).
* It would not otherwise change the value of the annotation, in case I missed 
any.

Since the two functions would be so similar, hopefully either they would share 
a common implementation, or typing.get_type_hints() could be implemented on top 
of typing.get_annotations().

Guido, Eric, any thoughts?

--
components: Library (Lib)
messages: 390874
nosy: eric.smith, gvanrossum, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Add typing.eval_annotations()
type: enhancement
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

[issue42737] PEP 563: drop annotations for complex assign targets



Guido van Rossum  added the comment:

Batuhan, can you summarize the argument from the thread? What do you think 
yourself? Myself, I'm not sure either way, but it seems okay to remove the 
remnant bytecode.

--

___
Python tracker 

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

[issue42904] get_type_hints does not provide localns for classes



Guido van Rossum  added the comment:

Hi Ken Jin, you can close this issue now with your new permissions, right?

--

___
Python tracker 

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

[issue42904] get_type_hints does not provide localns for classes



Guido van Rossum  added the comment:


New changeset 852150ddfe68bc2696fc880175aeb855a0c16ae6 by Ken Jin in branch 
'master':
bpo-42904: Fix get_type_hints for class local namespaces (GH-24201)
https://github.com/python/cpython/commit/852150ddfe68bc2696fc880175aeb855a0c16ae6


--

___
Python tracker 

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

[issue42059] TypedDict(...) as function does not respect "total" when setting __required_keys and optional_keys__



Guido van Rossum  added the comment:

Dominic, thanks so much for the backport!

--

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Andrew V. Jones  added the comment:

> 1) The Cython-generated code uses `Py_ISSPACE` (and not `_Py_ctype_table`), 
> but the expansion of the macro `Py_ISSPACE` then adds `_Py_ctype_table` to 
> the user's code
>

I wrote this up as a Cython bug here (just to see if the Cython team consider 
this "their" bug): https://github.com/cython/cython/issues/4111

--

___
Python tracker 

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

[issue43492] Upgrade to SQLite 3.35.4 in macOS and Windows



Steve Dower  added the comment:

It's been a busy month for the SQLite team... hope they're doing okay.

Let's give this one a few weeks, just in case.

--

___
Python tracker 

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

[issue43123] email MIME splitting

2021-04-12 Thread Ross Rhodes


Ross Rhodes  added the comment:

PR now “stale” since I have not received any feedback, yet.

--

___
Python tracker 

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

[issue42916] Support for DICOM image file format in imghdr module

2021-04-12 Thread Ross Rhodes


Ross Rhodes  added the comment:

PR already open to support DICOM based on the first 132 characters. Marked 
“stale” since I haven’t had any feedback on GitHub, yet.

--

___
Python tracker 

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

[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching

2021-04-12 Thread Brandt Bucher



Brandt Bucher  added the comment:

> For named tuples, there isn't an include/exclude option, so no extra mention 
> is warranted.

I think a note in the docs could still be valuable, if only because defining 
__match_args__ for named tuples changes the inherited tuple behavior for 
positional matches quite significantly: "case tuple(x)" and "case MyNT(x)" 
don't mean the same thing.

(Although perhaps this could be inferred from the new constructor signature.)

--

___
Python tracker 

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

[issue43492] Upgrade to SQLite 3.35.4 in macOS and Windows

2021-04-12 Thread Big Stone



Big Stone  added the comment:

3.35.4 is there

--
nosy: +Big Stone

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Change by Karthikeyan Singaravelan :


--
components: +C API

___
Python tracker 

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

[issue41661] os.path.relpath does not document ValueError on Windows with different drives

2021-04-12 Thread miss-islington



miss-islington  added the comment:


New changeset de06baa9de109a00c26de0dc5a248fe7aafe09f5 by Miss Islington (bot) 
in branch '3.9':
bpo-41661: Document os.path.relpath() exception on Windows with different 
drives (GH-25346)
https://github.com/python/cpython/commit/de06baa9de109a00c26de0dc5a248fe7aafe09f5


--

___
Python tracker 

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

[issue43797] Improve syntax error for invalid comparisons



Pablo Galindo Salgado  added the comment:


New changeset b86ed8e3bb41ede77eeab4a8bb4e2b91a8065283 by Pablo Galindo in 
branch 'master':
bpo-43797: Improve syntax error for invalid comparisons (#25317)
https://github.com/python/cpython/commit/b86ed8e3bb41ede77eeab4a8bb4e2b91a8065283


--

___
Python tracker 

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

[issue43797] Improve syntax error for invalid comparisons



Change by Pablo Galindo Salgado :


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

[issue43774] [Doc] Document configure options in the Python documentation



Pablo Galindo Salgado  added the comment:


New changeset 2459b92a4db69d9b14d0a86a9b81cc075894e910 by Victor Stinner in 
branch 'master':
bpo-43774: Remove --without-cycle-gc doc (GH-25364)
https://github.com/python/cpython/commit/2459b92a4db69d9b14d0a86a9b81cc075894e910


--
nosy: +pablogsal

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Andrew V. Jones  added the comment:

> I am happy to re-assign this as a Cython bug, but the fact it is fixed with 
> an `extern "C"` in Python.h, really makes it feel like it is a Python-proper 
> issue and not a "user" issue.
>

Just to extend on this:

1) The Cython-generated code uses `Py_ISSPACE` (and not `_Py_ctype_table`), 
but the expansion of the macro `Py_ISSPACE` then adds `_Py_ctype_table` to the 
user's code

2) The "user-fix" is to wrap `#include ` in `extern "C"` -- 
however, given other parts of Python.h already do this, it seems extraneous to 
expect a C++ user to wrap Python.h in this way

--

___
Python tracker 

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

[issue42248] Raised exception in Enum keeping user objects alive unnecessarily



Ethan Furman  added the comment:


New changeset 8c14f5a787b21d5a1eae5d5ee981431d1c0e055f by Ethan Furman in 
branch 'master':
bpo-42248: [Enum] ensure exceptions raised in ``_missing_`` are released 
(GH-25350)
https://github.com/python/cpython/commit/8c14f5a787b21d5a1eae5d5ee981431d1c0e055f


--

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Andrew V. Jones  added the comment:

> In fact, _Py_ctype_table is limited to the internal parts of the interpreter. 
> So in this case, this one could not be used in an external tool.
>

Hmm, so why is this "exposed" by the "world-facing" `Python.h` file?

I should say: we found this bug via Cython; and it was Cython that was 
accessing/referring to `_Py_ctype_table` -- our Cythonated code pulls in C++ 
headers, so we need to compile these files as C++.

I am happy to re-assign this as a Cython bug, but the fact it is fixed with an 
`extern "C"` in Python.h, really makes it feel like it is a Python-proper issue 
and not a "user" issue.

--

___
Python tracker 

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

[issue41661] os.path.relpath does not document ValueError on Windows with different drives



Change by Steve Dower :


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

[issue41661] os.path.relpath does not document ValueError on Windows with different drives



Steve Dower  added the comment:


New changeset 67c0b3d89c4da9750fdb43fc66d3924681b22d2e by Zackery Spytz in 
branch 'master':
bpo-41661: Document os.path.relpath() exception on Windows with different 
drives (GH-25346)
https://github.com/python/cpython/commit/67c0b3d89c4da9750fdb43fc66d3924681b22d2e


--

___
Python tracker 

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

[issue41661] os.path.relpath does not document ValueError on Windows with different drives

2021-04-12 Thread miss-islington



Change by miss-islington :


--
pull_requests: +24101
pull_request: https://github.com/python/cpython/pull/25367

___
Python tracker 

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

[issue41661] os.path.relpath does not document ValueError on Windows with different drives

2021-04-12 Thread miss-islington



Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +24100
pull_request: https://github.com/python/cpython/pull/25366

___
Python tracker 

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

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path



Change by Steve Dower :


--
assignee:  -> steve.dower
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

[issue43816] Missing 'extern "C"' for _Py_ctype_table

2021-04-12 Thread Stéphane Wirtel


Stéphane Wirtel  added the comment:

In fact, _Py_ctype_table is limited to the internal parts of the interpreter. 
So in this case, this one could not be used in an external tool.

You can read: https://docs.python.org/3/c-api/stable.html

I am not sure that you correctly use the API.

--
nosy: +matrixise

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table



Change by Andrew V. Jones :


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

___
Python tracker 

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

[issue43816] Missing 'extern "C"' for _Py_ctype_table


New submission from Andrew V. Jones :

With Python 3.9.4, and when compiling with Visual Studio 2019, we have noticed 
that the variable `_Py_ctype_table` is *not* scoped with in an `extern "C"` 
block, and where the Python library (`python39.lib`) *has* been compiled with a 
C compiler.

This causes an issue when trying to refer to `_Py_ctype_table` from a C++ file, 
as the compiler tries to name-mangle the _use_ of `_Py_ctype_table`, but the 
linker cannot then tie the mangled name to non-mangled named from  
`python39.lib`.

Example:

```
#include "Python.h"
int main() { return _Py_ctype_table[0]; }
```

Compilation:

```
cl.exe /Fe:test.exe /TP /I include test.cpp /link libs/python39.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29336 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 14.28.29336.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
libs/python39.lib
test.obj
test.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) 
unsigned int const * const _Py_ctype_table" (__imp_?_Py_ctype_table@@3QBIB) 
referenced in function main
test.exe : fatal error LNK1120: 1 unresolved externals
```

With `cl.exe`:

```
cl.exe /Bv  
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29336 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Compiler Passes:
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\cl.exe:
Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c1.dll:
Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c1xx.dll:  
Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c2.dll:
Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\c1xx.dll:  
Version 19.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\link.exe:  
Version 14.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\mspdb140.dll:  
Version 14.28.29336.0
 Z:\home\avj\visual_studio\MSVC\14.28.29333\bin\HostX64\x64\1033\clui.dll: 
Version 19.28.29336.0
```

A naïve check of Python.h (e126547c07) seems to suggest that:

* There are 82 includes

* 64 of these contain `extern "C"`

* 8 do not contain `extern "C"`

* The remaining 10 are either system includes or pyconfig.h

For the 8 that *do not* contain `extern "C"`, none of these use `PyAPI_DATA`. 
This leads me to believe that it is an oversight that `pyctype.h` does not have 
`extern "C"`

--
messages: 390855
nosy: andrewvaughanj
priority: normal
severity: normal
status: open
title: Missing 'extern "C"' for _Py_ctype_table
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

[issue43774] [Doc] Document configure options in the Python documentation



Change by STINNER Victor :


--
pull_requests: +24098
pull_request: https://github.com/python/cpython/pull/25364

___
Python tracker 

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

[issue43774] [Doc] Document configure options in the Python documentation



Change by STINNER Victor :


--
pull_requests: +24097
pull_request: https://github.com/python/cpython/pull/25363

___
Python tracker 

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

[issue43815] documentation for types.new_class() mention misleading default for exec_body



New submission from Eric V. Smith :

https://github.com/python/cpython/blob/3.8/Lib/types.py

The documentation says "If no callback is provided, it has the same effect as 
passing in lambda ns: ns."

I read this as saying that the callback should return the namespace, but in 
reality the return value is ignored. I think the lambda should be "lambda ns: 
None".

--
assignee: docs@python
components: Documentation
keywords: easy, newcomer friendly
messages: 390854
nosy: docs@python, eric.smith
priority: normal
severity: normal
status: open
title: documentation for types.new_class() mention misleading default for 
exec_body
versions: Python 3.10, 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

[issue33927] Allow json.tool to have identical infile and outfile

2021-04-12 Thread Stéphane Wirtel


Stéphane Wirtel  added the comment:

Hello @pablogsal,

What do you think about the PR of Rémi?

Thank you,

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

[issue43351] `RecursionError` during deallocation