[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?
Mark Williams added the comment: As a user of Python who maintains at least one large code base, I rely on coverage to limit the damage my changes can inflict. Some of the code I maintain uses __debug__; I would not expect moving to 3.8 to be the cause of reduced line coverage in that project, and I would be baffled by the difference between a coverage report from 3.8 and < 3.8. Please don't break a package as fundamental as coverage. Can the compiler be changed to not emit bytecode under some circumstances? -- nosy: +Mark.Williams ___ Python tracker <https://bugs.python.org/issue37500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36170] posix_spawn doesn't exist in 3.7
New submission from Mark Williams : The 3.8 docs claim that os.posix_spawn was introduced in 3.7, but it wasn't; it will be introduced in 3.8. https://docs.python.org/3.8/library/os.html#os.posix_spawn -- assignee: docs@python components: Documentation messages: 337027 nosy: Mark.Williams, docs@python priority: normal severity: normal status: open title: posix_spawn doesn't exist in 3.7 versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36170] posix_spawn doesn't exist in 3.7
Change by Mark Williams : -- keywords: +patch pull_requests: +12143 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue991266] Cookie.py does not correctly quote Morsels
Mark Williams added the comment: This patch only quotes the Comment attribute, and the rest of the code only quotes attributes if they're of the expected type. Consider Expires: >>> from http.cookies import SimpleCookie >>> c = SimpleCookie() >>> c['name'] = 'value' >>> c['name']['comment'] = '\n' >>> c['name']['expires'] = 123 >>> c.output() 'Set-Cookie: name=value; Comment="\\012"; expires=Fri, 20 Apr 2018 02:03:13 GMT' >>> c['name']['expires'] = '123; path=.example.invalid' 'Set-Cookie: name=value; Comment="\\012"; expires=123; path=.example.invalid' Here's the offending line: https://github.com/python/cpython/blob/b87c1c92fc93c5733cd3d8606ab2301ca6ba208f/Lib/http/cookies.py#L415 Why not quote all attribute values? -- nosy: +Mark.Williams versions: +Python 3.4 ___ Python tracker <https://bugs.python.org/issue991266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27759] selectors incorrectly retain invalid file descriptors
New submission from Mark Williams:
Registering a file descriptor with EpollSelector.register that epoll(7) refuses
results in the selector retaining a SelectorKey for that file descriptor, even
though it's not monitored.
The following program attempts to register a file on the filesystem with an
EpollSelector. epoll_ctl(2) returns EPERM when given a such a file descriptor,
so it shouldn't be registered with the selector, but it is registered.
import selectors
import tempfile
import traceback
sel = selectors.EpollSelector()
with tempfile.TemporaryFile() as f:
try:
sel.register(f, selectors.EVENT_READ)
except PermissionError:
traceback.print_exc()
print("This should have raised a KeyError:", sel.get_key(f))
It produces this output on Pythons 3.4-3.6:
Traceback (most recent call last):
File "/tmp/sel.py", line 9, in
sel.register(f, selectors.EVENT_READ)
File "/usr/lib/python3.4/selectors.py", line 402, in register
self._epoll.register(key.fd, epoll_events)
PermissionError: [Errno 1] Operation not permitted
This should have raised a KeyError: SelectorKey(fileobj=<_io.BufferedRandom
name=8>, fd=8, events=1, data=None)
A similar problem exists with KqueueSelector. Consider the following program:
import selectors
import tempfile
import traceback
sel = selectors.KqueueSelector()
f = tempfile.TemporaryFile()
filedescriptor = f.fileno()
f.close()
try:
sel.register(filedescriptor, selectors.EVENT_READ)
except OSError:
traceback.print_exc()
print("This should have raised a KeyError:", sel.get_key(filedescriptor))
In this case selectors._fileobj_to_fd doesn't detect that the integer file
descriptor is closed.
Note that _fileobj_to_fd should not be changed! Attempting to use, say,
fcntl(fd, fcntl.GET_FD) to detect a closed file descriptor introduces a TOCTTOU
bug. Another thread (or another process, if the file descriptor refers to a
socket shared between two or more processes and one calls shutdown(2) on it)
can change the state of the file descriptor between the time it's checked and
the time it's registered. A new file might even be opened and given the
previous file descriptor.
The attached patch catches any exception raised by EpollSelector.register or
KqueueSelector.register, removes the SelectorKey from BaseSelector's table, and
then re-raises the exception.
Note that I've included asyncio as an affected component, because asyncio wraps
the selectors module.
--
components: asyncio
files: selectors.patch
keywords: patch
messages: 272626
nosy: Mark.Williams, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: selectors incorrectly retain invalid file descriptors
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file44100/selectors.patch
___
Python tracker
<http://bugs.python.org/issue27759>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27759] selectors incorrectly retain invalid file descriptors
Mark Williams added the comment: Whoops! I pulled from https://github.com/python/cpython and branched off of master. The previous commit was https://github.com/python/cpython/tree/043152b8da83105ff5cba88d4e6ef1d5c64b3602 I can generate new patches using hg.python.org's 3.4 and 3.5 branches. Please stand by. -- ___ Python tracker <http://bugs.python.org/issue27759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27759] selectors incorrectly retain invalid file descriptors
Mark Williams added the comment: OK! Sorry for the trouble. On Sat, Aug 13, 2016 at 6:17 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Also don't spend more time on this, I found a way to apply the patch > cleanly. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue27759> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25341] File mode wb+ appears as rb+
New submission from Mark Williams:
There is at least one mode in which a file can be opened that cannot be
represented in its mode attribute: wb+. This mode instead appears as 'rb+' in
the mode attribute:
Python 3.5.0 (default, Oct 3 2015, 10:40:38)
[GCC 4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)]
on freebsd10
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> if os.path.exists('some_file'): os.unlink('some_file')
...
>>> with open('some_file', 'r+b') as f: print(f.mode)
...
Traceback (most recent call last):
File "", line 1, in
FileNotFoundError: [Errno 2] No such file or directory: 'some_file'
>>> with open('some_file', 'w+b') as f: print(f.mode)
...
rb+
>>> with open('some_file', 'r+b') as f: print(f.mode)
rb+
This means code that interacts with file objects cannot trust the mode of
binary files. For example, you can't use tempfile.TemporaryFile (the mode
argument of which defaults to 'wb+') and GzipFile:
>>> import gzip
>>> from tempfile import TemporaryFile
>>> with TemporaryFile() as f:
... gzip.GzipFile(fileobj=f).write(b'test')
...
Traceback (most recent call last):
File "", line 2, in
File "/usr/local/lib/python3.5/gzip.py", line 249, in write
raise OSError(errno.EBADF, "write() on read-only GzipFile object")
OSError: [Errno 9] write() on read-only GzipFile object
This occurs because without a mode argument passed to its initializer, GzipFile
checks that the fp object's mode starts with 'w', 'a', or 'x'.
For the sake of completeness/searchability: w+ and r+ are different modes, so
rb+ and wb+ must be different modes. Per
https://docs.python.org/3/library/functions.html#open :
"""
For binary read-write access, the mode 'w+b' opens and truncates the file to 0
bytes. 'r+b' opens the file without truncation.
"""
I haven't been able to test this on Windows, but I expect precisely the same
behavior given my understanding of the relevant source.
_io_FileIO___init___impl in _io/fileio.c does the right thing and includes
O_CREAT and O_TRUNC in the open(2) flags upon seeing 'w' in the mode:
https://hg.python.org/cpython/file/3.5/Modules/_io/fileio.c#l324
this ensures correct interaction with the file system. But it also sets
self->readable and self->writable upon seeing '+' in the mode:
https://hg.python.org/cpython/file/3.5/Modules/_io/fileio.c#l341
The open flags are not retained. Consequently, when the mode attribute is
accessed and the get_mode calls the mode_string function, the instance has
insufficient information to differentiate between 'rb+' and 'wb+':
https://hg.python.org/cpython/file/3.5/Modules/_io/fileio.c#l1043
If the FileIO instance did retain the 'flags' variable that's declared and set
in its initializer, then mode_string could use it to determine the difference
between wb+ and rb+.
I would be happy to write a patch for this.
--
components: IO, Interpreter Core, Library (Lib)
messages: 252518
nosy: Mark.Williams
priority: normal
severity: normal
status: open
title: File mode wb+ appears as rb+
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue25341>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25341] File mode wb+ appears as rb+
Mark Williams added the comment: Python's test suite may test the current behavior but that does not lessen the problem. I gave an example of apparently correct code that fails (that was actually encountered by a Python user) in my original description. Another such example: you cannot duplicate a file object -- same path, same mode --- and be sure that the duplicate is a true duplicate. Data corruption could occur in application code if the duplicated file were opened "rb+" instead of "wb+", as the duplicate would not truncate existing data. Another way to think about the problem is accuracy of intent. The mode attribute on file objects can be incorrect, and by "incorrect" I mean "not describe the mode under which the file was opened." Why have a mode attribute at all, then? I, for one, would prefer *no* mode attribute to one that's sometimes incorrect. But a correct one is even better! On Sat, Oct 10, 2015 at 1:27 AM, Xiang Zhang wrote: > > Xiang Zhang added the comment: > > I think Mark is right. Since wb+ and rb+ have different behaviours they > should be treat separately. > > But this behaviour treating wb+ and rb+ as the same is well tested and > seems to intended to do so. > > -- > nosy: +xiang.zhang > > ___ > Python tracker > <http://bugs.python.org/issue25341> > ___ > -- ___ Python tracker <http://bugs.python.org/issue25341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
