[issue33033] Clarify that the signed number convertors to PyArg_ParseTuple... *do* overflow checking

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This doesn't look a good idea to me. It is implied that all checks are 
performed. For example it is implied that an error will be raised if the 
argument is of wrong type. I think that adding "with overflow checking" to 
every converting from a Python integer will just clutter the documentation.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

[Nathan Henrie]

Nathan Henrie  added the comment:

It seems to work if you close proto.transport (as is done in 
`test_write_pty()`).

--

___
Python tracker 

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

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

[Nathan Henrie]

Change by Nathan Henrie :


--
keywords: +patch
pull_requests: +5799
stage: needs patch -> patch review

___
Python tracker 

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

[issue28626] Tutorial: rearrange discussion of output formatting to encourage f-strings

[A.M. Kuchling]

Change by A.M. Kuchling :


--
pull_requests: +5798

___
Python tracker 

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

[issue33033] Clarify that the signed number convertors to PyArg_ParseTuple... *do* overflow checking

[Antony Lee]

New submission from Antony Lee :

At https://docs.python.org/3/c-api/arg.html#numbers, it is explicitly 
documented that the unsigned number convertors do not perform overflow 
checking.  Implicitly, this suggests that the signed convertors *do* perform 
overflow checking, which they indeed do; but it would be nice to document this 
behavior explicitly (as overflow checking is not always expected of C-level 
functions).

--
assignee: docs@python
components: Documentation
messages: 313471
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: Clarify that the signed number convertors to PyArg_ParseTuple... *do* 
overflow checking
versions: Python 3.6

___
Python tracker 

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

[issue33032] Mention implicit cache in struct.Struct docs

[Nick Coghlan]

Nick Coghlan  added the comment:

The note on https://docs.python.org/3/library/re.html#re.compile provides a 
useful precedent for possible wording here, as the struct cache and the regex 
cache are quite similar.

--

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> We know that the path is valid because we have a handle (in this case the 
> file system ensures that no parent directory in the path can be unlinked or 
> renamed).

Thank you for pointing this out. I erroneously stated that the length of the 
path could increase between GetFinalPathNameByHandle calls because an 
intermediate directory could be renamed, but actually I've only checked that 
the last part can be renamed (or even deleted, though it'll still linger in 
inaccessible state until the handle is closed).

--

___
Python tracker 

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

[issue33032] Mention implicit cache in struct.Struct docs

[Nick Coghlan]

New submission from Nick Coghlan :

The struct.Struct docs claim that creating and re-using a Struct object will be 
noticeably faster than calling the module level methods repeatedly with the 
same format string, as it will avoid parsing the format string multiple times: 
https://docs.python.org/3/library/struct.html#struct.Struct

This claim is questionable, as struct has used an internal Struct cache since 
at least 2.5, so if you're using less than 100 different struct layouts in any 
given process, the only thing you'll be saving is a string-keyed dictionary 
lookup.

--
assignee: docs@python
components: Documentation
messages: 313468
nosy: docs@python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Mention implicit cache in struct.Struct docs
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> unless users are not prepared to deal with it
ARE prepared

> What do you think about handling this failure by calling GetFullPathName 
> instead (e.g. "C:\Temp\NUL" => "\\.\NUL")?

I think it would indeed be nice if pathlib handled such paths in its resolve(), 
especially since os.path.abspath() does handle them, and it looks weird that 
even resolve(strict=False) fails. That could be an enhancement, but note that 
it'll expose users to '\\.\'-prefixed paths which can't be returned from 
resolve() now. It is not necessary a problem because users should be prepared 
to handle UNC-like paths anyway.

> Currently pathlib's resolve method doesn't handle PermissionError like I 
> think it should in non-strict mode. It only handles FileNotFoundError

That behavior doesn't look good, and it's inconsistent with POSIX resolve() 
which doesn't propagate any OSError in non-strict mode. I think this warrants 
an issue report.

--

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> Because we only try VOLUME_NAME_DOS, this function always fails for a volume 
> that's not mounted as either a drive letter or a junction mount point.

If a volume is not mounted, users have to use \\?\ or \\.\ either directly or 
indirectly via a symlink or a junction to get to it, right? Do you think such 
uses are common enough to warrant dealing with VOLUME_NAME_GUID? Also note that 
pathlib currently expects DOS paths only: it will strip '\\?\' prefix in 
resolve(), making GUID path "invalid" (and, also, precluding direct usage of 
'\\?\' prefix with resolve() in other cases unless users are not prepared to 
deal with it).

--

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Steve Dower]

Steve Dower  added the comment:

Leaving this open for commit review (and buildbots) for a little while, but 
then I'll close it if we're all good.

--
assignee:  -> steve.dower
stage: patch review -> commit review

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Steve Dower]

Steve Dower  added the comment:


New changeset 32efcd13069a89abf007373274ee1bc0909d1996 by Steve Dower in branch 
'3.6':
bpo-33016: Fix potential use of uninitialized memory in nt._getfinalpathname 
(GH-6032)
https://github.com/python/cpython/commit/32efcd13069a89abf007373274ee1bc0909d1996


--

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

Copying the comment of @eryksun from PR 6010 for reference.

Because we only try VOLUME_NAME_DOS, this function always fails for a volume 
that's not mounted as either a drive letter or a junction mount point. The 
error in this case is ERROR_PATH_NOT_FOUND. We know that the path is valid 
because we have a handle (in this case the file system ensures that no parent 
directory in the path can be unlinked or renamed). To address this, if the 
flags parameter isn't already VOLUME_NAME_GUID, it could switch to it and 
continue the while loop (no need to realloc). Otherwise if it's already 
VOLUME_NAME_GUID or for any other error, the call should fail.

For DOS devices in paths (e.g. "C:\Temp\NUL"), CreateFile commonly succeeds, 
but GetFinalPathNameByHandle commonly fails with either ERROR_INVALID_FUNCTION 
or ERROR_INVALID_PARAMETER. What do you think about handling this failure by 
calling GetFullPathName instead (e.g. "C:\Temp\NUL" => "\\.\NUL")? That way 
most DOS device paths won't cause this function to fail (e.g. when called by 
pathlib's resolve method). We could do the same if CreateFile fails with 
ERROR_INVALID_PARAMETER, which should only occur for CON (e.g. "C:\Temp\CON") 
because it needs to be opened with either generic read or generic write access.

CreatFile also commonly fails here with either ERROR_SHARING_VIOLATION (from a 
paging file) or ERROR_ACCESS_DENIED. But I think those are best handled by the 
caller, with a PermissionError exception handler. Currently pathlib's resolve 
method doesn't handle PermissionError like I think it should in non-strict 
mode. It only handles FileNotFoundError

--

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

@eryksun Very interesting! BTW, I looked at CreateFile docs, and the fact that 
it may set the last error to zero is even documented there.

@steve.dower
> maybe we don't have to preserve errno on Windows?

There are still places where errno is relied upon. PR 5784 shows one such 
place: os.[f]truncate(). Others are e.g. os.open() and os.lseek().

--

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Eryk Sun]

Eryk Sun  added the comment:

FYI, here's a sampling of successful calls that modify the last error value.

Most Create- functions intentionally set the last error to 0 on success, such 
as CreateFile, CreateFileMapping, CreateSymbolicLink, CreateJobObject, 
CreateEvent, CreateMutex, CreateSemaphore, and CreateWaitableTimer. 

Some other functions also intentionally set the last error to 0 on success, 
such as SetWaitableTimer and the functions that work with security identifiers 
(SIDs) such as EqualSid, GetLengthSid, GetSidIdentifierAuthority, and 
GetSidSubAuthority.

The return value of some functions is the low DWORD of a file size, such as 
GetCompressedFileSize, GetFileSize, and SetFilePointer. In this case 0x 
is either a valid size or indicates an error. The function is forced to clarify 
this by setting the last error to 0 on success. GetFileSizeEx and 
SetFilePointerEx are preferred, since they don't have this problem.

Some functions make internal calls to CreateFile or DeviceIoControl. These 
cases might even set the last error to a non-zero value on success. Examples 
include GetVolumePathName (e.g. ERROR_MORE_DATA from DeviceIoControl), 
GetFinalPathNameByHandle (opening  "\\.\MountPointManager"), and GetDriveType 
(e.g. for junction mountpoints).

--
nosy: +eryksun

___
Python tracker 

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

[issue32642] add support for path-like objects in sys.path

[Jay Yin]

Jay Yin  added the comment:

The issue was resolved by updating my version of the rest of the package 
apparently and remaking the whole thing, must have been some outdated stuff on 
my end causing the issue

--

___
Python tracker 

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

[issue33023] Unable to copy ssl.SSLContext

[Vitaly Kruglikov]

Vitaly Kruglikov  added the comment:

Also, updating ssl.SSLContext documentation about intentional inability to copy 
generically and suggestion how to go about it if you need to obtain a clone or 
similar would be terrific and save developers time so they won't run into this 
gotcha when designing and implementing solutions. Many thanks!

--

___
Python tracker 

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

[issue33023] Unable to copy ssl.SSLContext

[Vitaly Kruglikov]

Vitaly Kruglikov  added the comment:

Hi Christian, thank you for following up. Here is my use case, and perhaps you 
can suggest something else that will work:

I am refactoring the transport layer in the Pika AMQP client library. The user 
provides an ssl.SSLContext instance for connecting to an AMQP broker (e.g., 
RabbitMQ). Pika will resolve the hostname via getaddrinfo and make attempts to 
establish TCP and AMQP connection to the candidate IP addresses until one 
succeeds in establishing an AMQP connection over SSL. Each connection attempt 
will require a fresh unadulterated clone of the ssl.SSLContext instance 
provided by user to avoid any side-effects from prior connection attempts.

How can I obtain this pristine clone cleanly for each new connection attempt?

--

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Steve Dower]

Steve Dower  added the comment:

> Before take_gil() knows whether it has to do any work

I thought we had a check for when the GIL was not even initialized, but that 
doesn't seem to exist in master any more.

Preserving GetLastError() at the same place we do errno is probably sufficient. 
There shouldn't be any more of a performance penalty (and maybe we don't have 
to preserve errno on Windows? That will save a TLS lookup at least)

--

___
Python tracker 

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

[issue32981] Catastrophic backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)

[Ned Deily]

Change by Ned Deily :


--
keywords: +security_issue
nosy: +larry
priority: normal -> critical
title: Catastrophic backtracking in poplib and difflib -> Catastrophic 
backtracking in poplib (CVE-2018-1060) and difflib (CVE-2018-1061)
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 
3.8

___
Python tracker 

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

[issue26701] Documentation for int constructor mentions __int__ but not __trunc__

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What about __floor__ and __ceil__?

I think all these three method do not deserve separate paragraphs in 
Doc/reference/datamodel.rst, but they should be grouped together with __round__.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32972] unittest.TestCase coroutine support

[Nathaniel Smith]

Nathaniel Smith  added the comment:

You should also think about loop lifecycle: right now it's using the same loop 
for all test cases, so callbacks can leak between tests. Twisted actually goes 
a step further and explicitly checks for left over callbacks and fails the test 
if any are found.

--

___
Python tracker 

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

[issue32981] Catastrophic backtracking in poplib and difflib

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +5797

___
Python tracker 

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

[issue32981] Catastrophic backtracking in poplib and difflib

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +5796

___
Python tracker 

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

[issue33029] Invalid function cast warnings with gcc 8 for getter and setter functions

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.8

___
Python tracker 

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

[issue32972] unittest.TestCase coroutine support

[Petter S]

Petter S  added the comment:

> 1. Do we need support for async versions of setUp, setUpClass, etc?  In my 
> opinion: yes.

I completely agree. I would imagine many or most real-world tests requiring 
async setUp. There is also the question on how a custom loop etc. can be used 
in the unit test class.

How about this: unittest.TestCase gets a very small refactor in which a 
overridable helper method is used to run the test method. This helper method 
can then be changed to run async methods in a subclass AsyncioTestCase (that 
probably should live in asyncio).

Pull request 6005 contained such a helper method, but the async part could be 
implemented in the subclass instead.

--

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> Ideally, if we don't have to do any work to reacquire the GIL, we shouldn't 
> do any work to preserve the error code either.

Before take_gil() knows whether it has to do any work, it calls 
MUTEX_LOCK(_PyRuntime.ceval.gil.mutex), which is either EnterCriticalSection() 
or AcquireSRWLockExclusive(). So unless we can be sure that those functions 
can't clobber the last error (or we redesign GIL to have a fast-path like an 
atomic compare-exchange in non-contended case), I don't see how we can avoid 
the last error bookkeeping.

--

___
Python tracker 

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

[issue33031] Questionable code in OrderedDict definition

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The array of PyMethodDef for OrderedDict contains explicit definitions of 
methods like __delitem__, __eq__ and __init__. The purpose is aligning 
docstrings with Python implementation. But this doesn't work. Slot wrappers 
replace these descriptors. And docstings are standard docstrings for 
corresponding slot wrappers.

Thus this code doesn't work. And it looks dangerous, since functions are casted 
to incompatible function types. Even if they are never used, the compiler (gcc 
8) produces warnings (see issue33012). May be this is even undefined behavior. 
In that case the compiler can generate arbitrary code.

I suggest to remove these definitions.

--
components: Extension Modules
messages: 313452
nosy: eric.snow, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Questionable code in OrderedDict definition
type: compile error
versions: Python 3.8

___
Python tracker 

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

[issue29871] Enable optimized locks on Windows

[Alexey Izbyshev]

Change by Alexey Izbyshev :


--
nosy: +izbyshev

___
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 in Python 3.7

[Alexey Izbyshev]

Change by Alexey Izbyshev :


--
nosy: +izbyshev

___
Python tracker 

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

[issue32972] unittest.TestCase coroutine support

[Yury Selivanov]

Yury Selivanov  added the comment:

> That code does not seem to work for me:
> https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d
> I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited"

> @mock.patch needs to work correctly for test methods.
> [..]
> No, unittest.TestCase can handle this, as demonstrated by two PRs in this 
> bug. This would not change the behavior of existing (working) code.

Correct, and while it's possible to fix my little helper to work with mocks, 
you're completely right that we can, indeed, implement async support in 
TestCase without a metaclass.  My mistake here, thanks for correcting!

In any case, while I think we can now talk about augmenting TestCase, I'd still 
want to first discuss few other issues:

1. Do we need support for async versions of setUp, setUpClass, etc?  In my 
opinion: yes.

2. There're a few options how to implement (1):

a) Add async support to TestCase. Automatically detect when a test is async, or 
when 'setUp' and friends are async and run them all with 'asyncio.run'.

b) Add async support to TestCase.  Add asyncSetUp, asyncSetUpClass, etc magic 
methods.  The argument in favour of this approach over (a) is that it's 
possible to safely use 'super()' calls when you have multiply inherited 
TestCases.

c) Add a new AsyncioTestCase specifically for working with asyncio (combine 
with option (b)).

I still don't like (a) because it involves too much implicit logic.  I think 
that it's simple enough to inherit your testcase from unittest.AsyncioTestCase 
and read a separate documentation specifically about it and not about generic 
TestCase.

--

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Steve Dower]

Steve Dower  added the comment:

> GetLastError() docs officially scare us

I believe this is a case where the docs were updated from intended/correct 
behavior to actual behavior, which happens from time to time and is never 
clearly marked.

As I say, they are _supposed_ to leave the error unchanged unless they return a 
value that indicates an error occurred, but some APIs behave incorrectly. The 
docs are simply documenting that fact. (It turns out reality is more useful 
than fantasy ;) though I do wish they were clearer about that)

--

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

FWIW, GetLastError() docs[1] officially scare us:

Most functions that set the thread's last-error code set it when they fail. 
However, some functions also set the last-error code when they succeed. If the 
function is not documented to set the last-error code, the value returned by 
this function is simply the most recent last-error code to have been set; some 
functions set the last-error code to 0 on success and others do not.

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx

--
nosy: +izbyshev

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[miss-islington]

miss-islington  added the comment:


New changeset 8c163bbf370f6f6cedd2c07f7d54c9b36c97d8f2 by Miss Islington (bot) 
in branch '3.7':
bpo-33016: Fix potential use of uninitialized memory in nt._getfinalpathname 
(GH-6010)
https://github.com/python/cpython/commit/8c163bbf370f6f6cedd2c07f7d54c9b36c97d8f2


--
nosy: +miss-islington

___
Python tracker 

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

[issue33030] GetLastError() may be overwritten by Py_END_ALLOW_THREADS

[Steve Dower]

New submission from Steve Dower :

Most Win32 API calls are made within Py_BEGIN_ALLOW_THREADS blocks, as they do 
not access Python objects and so we can release the GIL.

However, in general, error handling occurs after the Py_END_ALLOW_THREADS line. 
Due to the design of the Win32 API, the pattern looks like this:

Py_BEGIN_ALLOW_THREADS
ret = ApiCall(...);
Py_END_ALLOW_THREADS
if (FAILED(ret)) {
error_code = GetLastError();
}

However, Py_END_ALLOW_THREADS also makes Win32 API calls (to acquire the GIL), 
and if any of these fail then the error code may be overwritten.

Failures in Py_END_ALLOW_THREADS are either fatal (in which case we don't care 
about the preceding error any more) or signal a retry (in which case we *do* 
care about the preceding error), but in the latter case we may have lost the 
error code.

Further, while Win32 APIs are not _supposed_ to set the last error to 
ERROR_SUCCESS (0) when they succeed, some occasionally do.

We should update Py_END_ALLOW_THREADS to preserve the last error code when 
necessary. Ideally, if we don't have to do any work to reacquire the GIL, we 
shouldn't do any work to preserve the error code either.

--
components: Windows
messages: 313447
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: GetLastError() may be overwritten by Py_END_ALLOW_THREADS
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue28113] Remove Py_CreateSymbolicLinkW

[Steve Dower]

Steve Dower  added the comment:

We should look at merging this, though we need a few things to be done first 
(anyone can jump in and do these, doesn't have to be Eryk):

* patch needs to be converted to a GitHub PR
* we should use unique names within %TEMP% to avoid conflicts between tests 
running in parallel
* PEP 7 has changed since the original patch
* NEWS and maybe a What's New entry?

--
versions: +Python 3.8

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +5795

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[miss-islington]

Change by miss-islington :


--
pull_requests: +5794

___
Python tracker 

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

[issue33016] nt._getfinalpathname may use uninitialized memory

[Steve Dower]

Steve Dower  added the comment:


New changeset 3b20d3454e8082e07dba93617793de5dc9237828 by Steve Dower (Alexey 
Izbyshev) in branch 'master':
bpo-33016: Fix potential use of uninitialized memory in nt._getfinalpathname 
(#6010)
https://github.com/python/cpython/commit/3b20d3454e8082e07dba93617793de5dc9237828


--

___
Python tracker 

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

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

[Ned Deily]

Change by Ned Deily :


--
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed
versions: +Python 3.7

___
Python tracker 

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

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

[Ned Deily]

Ned Deily  added the comment:


New changeset 2f3ba27185a369bcb6b36b13aa3518ffcc970ffa by Ned Deily (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-30353: Fix pass by value for structs on 64-bit Cygwin/MinGW (GH-1559) 
(GH-5954)
https://github.com/python/cpython/commit/2f3ba27185a369bcb6b36b13aa3518ffcc970ffa


--
nosy: +ned.deily

___
Python tracker 

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

[issue33028] tempfile.TemporaryDirectory incorrectly documented

[Ned Deily]

Change by Ned Deily :


--
type: enhancement -> 

___
Python tracker 

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

[issue33028] tempfile.TemporaryDirectory incorrectly documented

[Ned Deily]

Change by Ned Deily :


--
nosy: +lars.gustaebel
versions: +Python 3.7, Python 3.8

___
Python tracker 

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

[issue33029] Invalid function cast warnings with gcc 8 for getter and setter functions

[Siddhesh Poyarekar]

New submission from Siddhesh Poyarekar :

gcc 8 has added a new warning heuristic to detect invalid function casts and a 
stock python build seems to hit that warning quite often.  bug 33012 fixes the 
most trivial case of METH_NOARGS, this bug is to track a similarly trivial but 
widely applicable fix, which is to cast getter and setter functions.

Patches coming up over the weekend.

--
components: Build
messages: 313443
nosy: siddhesh
priority: normal
severity: normal
status: open
title: Invalid function cast warnings with gcc 8 for getter and setter functions
type: compile error

___
Python tracker 

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

[issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS

[Siddhesh Poyarekar]

Change by Siddhesh Poyarekar :


--
keywords: +patch
pull_requests: +5792
stage:  -> patch review

___
Python tracker 

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

[issue33018] Improve issubclass() error checking and message

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

PR 5944 changes ABC.__subclasscheck__ (not issubclass) to check its first 
argument, so if it's merged there will be no crash even with the revert.

--

___
Python tracker 

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

[issue33018] Improve issubclass() error checking and message

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Can 
> https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c
>  be reverted?

Even if subclass() will check explicitly that its first argument is a type, 
ABC.__subclasscheck__() can be called directly, and it shouldn't crash when 
called with non-type.

--

___
Python tracker 

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

[issue33018] Improve issubclass() error checking and message

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

> Isn't it just a limitation?
> Most Python-implemented objects supports weakref. I don't think "requiring 
> weakref support implies it must be type object".

Formally, there is no implication. It is the abc module authors who know the 
truth. But I can't imagine why anybody would impose such a limitation by 
design, because while instances of user-defined classes support weakrefs, 
built-in classes used by everybody like tuple, list and dict don't. That's why 
I guessed that non-types were not meant to be supported.

> What "by OP" means?
OP = Original poster (@jab).

> I can't find `if not issubclass(cls, type): raise TypeError` in Reversible 
> implementation.
> They do duck-typing, same to ABC.

Sorry for being unclear. There is no explicit check as you say, but __mro__ is 
directly accessed (see msg313376). But it may probably be considered "duck 
typing" too.

> But I don't know much about how mages use ABC.  I need mages comment before 
> merging the pull request.
Totally agree.

> BTW, do you think it should be backported to 3.7, or even 3.6?
3.7 certainly has my vote -- this can hardly be considered a new feature.

For 3.6, I'd listen to ABC users/experts. Might raising a TypeError instead of 
returning False from issubclass(user_defined_obj, ABC) break something 
important? Personally, I think it would mostly expose bugs and not hinder 
reasonable usage.  

> Can 
> https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c
>  be reverted?

Seems like it can, but the test should survive in some form :)

--

___
Python tracker 

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

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

[Erik Bray]

Erik Bray  added the comment:

This has a backport PR now for 3.6.  Once that PR is merged I think we can 
close this as fixed.

--
stage: patch review -> backport needed
versions: +Python 3.6

___
Python tracker 

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

[issue32972] unittest.TestCase coroutine support

[Petter S]

Petter S  added the comment:

> No, it shouldn't break them if you wrap async methods carefully.
> Here's a metaclass that I wrote recently doing just that

That code does not seem to work for me:
https://gist.github.com/PetterS/f684095a09fd1d8164a4d8b28ce3932d
I get "RuntimeWarning: coroutine 'test_async_with_mock' was never awaited"

@mock.patch needs to work correctly for test methods.

>> I'm really not seeing what a separate class buys you.
> I already mentioned in my previous comments that adding async support to 
> unittest.TestCase would require us to add a metaclass to it, which is 
> potentially a backwards incompatible change.

No, unittest.TestCase can handle this, as demonstrated by two PRs in this bug. 
This would not change the behavior of existing (working) code.

--

___
Python tracker 

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

[issue33025] urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders

[Christian Heimes]

Change by Christian Heimes :


--
assignee: christian.heimes -> 

___
Python tracker 

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

[issue33023] Unable to copy ssl.SSLContext

[Christian Heimes]

Christian Heimes  added the comment:

This is rather a feature than a bug. It is not possible to make a copy of a 
SSLContext object because OpenSSL doesn't support the operation. A context 
contains elements that can't be cloned easily, e.g. session resumption tickets.

--

___
Python tracker 

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

[issue33018] Improve issubclass() error checking and message

[INADA Naoki]

INADA Naoki  added the comment:

> 1. ABCMeta.register() accepts types only.

Yes.  While ABC.register() and issubclass() have different users (e.g. 
ABC.register() will be used by  framework author, and issubclass will be used 
by framework users), it's positive reason to remove non-type support.

> 2. ABCMeta.__subclasscheck__ implicitly requires its arguments to support 
> weak references (regardless of whether __subclasshook__ is called or not). 
> This requirement alone doesn't make sense, so it seems to be an exposed 
> implementation detail stemming from the fact that non-types were not intended 
> to be supported.

Isn't it just a limitation?
Most Python-implemented objects supports weakref. I don't think "requiring 
weakref support implies it must be type object".


> 3. Some ABC users already expect that the argument of __subclasshook__ is a 
> type (see the example with collections.abc.Reversible by OP).

What "by OP" means?
I can't find `if not issubclass(cls, type): raise TypeError` in Reversible 
implementation.
They do duck-typing, same to ABC.


> 4. Attempting to support arbitrary arguments in ABC.__subclasscheck__ (by 
> returning False instead of raising TypeError or worse) will not solve any 
> 'issubclass' inconsistencies. 'issubclass' is fundamentally "fragmented": 
> issubclass(x, y) may return True/False while issubclass(x, z) may raise 
> TypeError, depending on __subclasscheck__ implementation.

Yes, as I commented above.

> It may be too late to impose stricter requirements for the first argument of 
> issubclass because 'typing' module relies on the support of non-types there.

Of course.


Personally speaking, I dislike magics including ABC, __subclasscheck__, 
overwriting __class__ with dummy object.  So I'm OK to limit the ability of it.

But I don't know much about how mages use ABC.  I need mages comment before 
merging the pull request.

BTW, do you think it should be backported to 3.7, or even 3.6?
Can 
https://github.com/python/cpython/commit/fc7df0e664198cb05cafd972f190a18ca422989c
 be reverted?

--

___
Python tracker 

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

[issue33024] asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value

[Andrew Svetlov]

Andrew Svetlov  added the comment:

We cannot change the method signature without breaking backward compatibility. 
I doubt if we should do something with the issue.

--

___
Python tracker 

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

[issue33021] Some fstat() calls do not release the GIL, possibly hanging all threads

[Nir Soffer]

Nir Soffer  added the comment:

Python cannot protect raw file descriptor from bad multi-threaded
application. For example the application may close a file descriptor twice
which may lead to closing unrelated file descriptor created by another
thread just after it was closed, before the second close.

This issue affects all function using raw file descriptors, and we cannot
protect them with the GIL.

Even if fstat was not thread safe, we cannot protect it using the GIl
since this blocks the entire application until fstat returns.

--

___
Python tracker 

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

[issue33018] Improve issubclass() error checking and message

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

I do not see any point in allowing non-types in ABCMeta.__subclasscheck__. 
Currently, ABCs are clearly not designed to support non-types:

1. ABCMeta.register() accepts types only.
2. ABCMeta.__subclasscheck__ implicitly requires its arguments to support weak 
references (regardless of whether __subclasshook__ is called or not). This 
requirement alone doesn't make sense, so it seems to be an exposed 
implementation detail stemming from the fact that non-types were not intended 
to be supported.
3. Some ABC users already expect that the argument of __subclasshook__ is a 
type (see the example with collections.abc.Reversible by OP).
4. Attempting to support arbitrary arguments in ABC.__subclasscheck__ (by 
returning False instead of raising TypeError or worse) will not solve any 
'issubclass' inconsistencies. 'issubclass' is fundamentally "fragmented": 
issubclass(x, y) may return True/False while issubclass(x, z) may raise 
TypeError, depending on __subclasscheck__ implementation. It may be too late to 
impose stricter requirements for the first argument of issubclass because 
'typing' module relies on the support of non-types there.

--

___
Python tracker 

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

[issue17288] cannot jump from a 'return' or 'exception' trace event

[Xavier de Gaye]

Xavier de Gaye  added the comment:

Sorry, for some reason github did not send me the emails of your review and I 
did not think about checking the PR :-(
Thanks for your review, I will work on it shortly.

--

___
Python tracker 

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

[issue33028] tempfile.TemporaryDirectory incorrectly documented

[Richard Neumann]

New submission from Richard Neumann :

The tempfile.TemporaryDirectory is incorrectly documented at 
https://docs.python.org/3.6/library/tempfile.html#tempfile.TemporaryDirectory.

It is described as a function, though actually being a class (unlinke 
tempfile.NamedTemporaryFile).
The respective property "name" and method "cleanup" are only documented in the 
continuous text but not explicitely highlighted as the properties and method of 
e.g. TarFile (https://docs.python.org/3/library/tarfile.html#tarfile-objects).

--
assignee: docs@python
components: Documentation
messages: 313431
nosy: Richard Neumann, docs@python
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory incorrectly documented
type: enhancement
versions: Python 3.6

___
Python tracker 

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

[issue33027] handling filename encoding in Content-Disposition by cgi.FieldStorage

[Paweł]

Change by Paweł :


--
keywords: +patch
pull_requests: +5790
stage:  -> patch review

___
Python tracker 

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

[issue33027] handling filename encoding in Content-Disposition by cgi.FieldStorage

[Paweł]

New submission from Paweł :

It appears that cgi.FieldStorage does not handle 
Content-Disposition with filenames with defined encoding.
(according to RFC5987)

Example:
'''
Content-Disposition: form-data; name="file"; 
filename*=utf-8''upload_test_file_%C5%82%C3%B3%C4%85%C3%A4.txt
'''

The way to reproduce this is to either try to parse above or
write a tiny webapp using a web framework that uses CGI for handling
file uploads (webpy) and try to upload a file using `requests` - or any library 
that uses urllib3 for building POST with multipart/form-data.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition

https://tools.ietf.org/html/rfc5987

--
components: Library (Lib)
messages: 313430
nosy: pawciobiel
priority: normal
severity: normal
status: open
title: handling filename encoding in Content-Disposition by cgi.FieldStorage
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue32972] unittest.TestCase coroutine support

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Class decorators are also worth considering in cases where you find yourself 
reaching for a metaclass.

--
nosy: +njs

___
Python tracker 

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

[issue17288] cannot jump from a 'return' or 'exception' trace event

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you Xavier. I had pleasure from reviewing your patch. But please update 
tests for using the jump_test() decorator.

--

___
Python tracker 

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

[issue33026] Fix jumping out of "with" block

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Well, it is not hard to fix this in older versions.

--
versions: +Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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