[issue22633] Memory disclosure/buffer overread via bug in Py_FrozenMain
New submission from Guido:
Python/frozenmain.c:27 -
https://hg.python.org/cpython/file/424fbf011176/Python/frozenmain.c#l27
Memory is allocated for sizeof(wchar_t*) * argc bytes. If argc is 0 (which is a
possibility, see below), then 0 bytes are attempted to allocate.
Note that PyMem_RawMalloc typically calls _PyMem_RawMalloc, which ensures that
a nonzero value is passed to malloc:
https://hg.python.org/cpython/file/424fbf011176/Objects/obmalloc.c#l60
In the case of argc == 1, we have the guarantee that one byte is allocated.
Then, this:
https://hg.python.org/cpython/file/424fbf011176/Python/frozenmain.c#l54 routine
fills the argv_copy array with values. However, if argc == 0, this code is
never reached.
https://hg.python.org/cpython/file/424fbf011176/Python/frozenmain.c#l71 then
sets the program name to argv_copy[0] using Py_SetProgramName().
The issue here is is that because argv_copy[0] may be uninitialized, it may be
a nonzero value, because, as far as I know, malloc doesn't give any guarantees
as to the initial values of the allocated values (hence the existence of
something like calloc).
If a pointer to a zero byte is passed to Py_SetProgramName(), the function
doesn't change progname:
https://hg.python.org/cpython/file/424fbf011176/Python/pythonrun.c#l884
But since there are no guarantees as to what argv_copy[0] is AND there are no
guarantees about the memory region that follows, a rare and unlikely though
theoretically possible situation may emerge where each time progname is
referenced (for example indirectly by reading to sys.executable), a string is
returned that contains bytes after argv_copy[0], resulting in a memory
disclosure.
Here's an example of how to run a program with zero arguments (argc == 0):
// https://stackoverflow.com/questions/8113786/executing-a-process-with-argc-0
#include
#include
int main(int argc, char** argv, char** envp)
{
pid_t pid;
char* zero_argv[] = {NULL};
posix_spawn(&pid, "./hello", NULL, NULL, zero_argv, envp);
int status;
waitpid(&pid, &status, NULL);
return 0;
}
I propose the following patch:
--- frozenmain.c2014-10-14 19:56:27.144705062 +0200
+++ new_frozenmain.c2014-10-14 19:59:16.800704366 +0200
@@ -24,13 +24,15 @@
/* We need a second copies, as Python might modify the first one. */
wchar_t **argv_copy2 = NULL;
-argv_copy = PyMem_RawMalloc(sizeof(wchar_t*) * argc);
+argv_copy = PyMem_RawMalloc(sizeof(wchar_t*) * (argc ? argc : 1));
argv_copy2 = PyMem_RawMalloc(sizeof(wchar_t*) * argc);
if (!argv_copy || !argv_copy2) {
fprintf(stderr, "out of memory\n");
goto error;
}
+argv_copy[0] = '\0';
+
Py_FrozenFlag = 1; /* Suppress errors from getpath.c */
if ((p = Py_GETENV("PYTHONINSPECT")) && *p != '\0')
By enforcing a minimal allocation of 1 byte in this file, we are guaranteed
that malloc doesn't return a non-zero value after it is called with malloc(0)
(this is possible, see man malloc) and we don't have to rely on the heap
allocator to do this (in case it's not _PyMem_RawMalloc).
Setting argv_copy[0] to zero ensures a buffer overread will never occur.
Tested only for Python 3.4.
Guido
--
messages: 229330
nosy: Guido
priority: normal
severity: normal
status: open
title: Memory disclosure/buffer overread via bug in Py_FrozenMain
type: security
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue22633>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1160] Medium size regexp crashes python
New submission from
Guido Ostkamp
:
Hello,
a medium size regular expression crashes Python 2.5.1 as follows:
Traceback (most recent call last):
File "./regtest.py", line 14, in
m = rematch(pats)
File "./regtest.py", line 12, in rematch
return re.compile(pat).match
File "/export/home/ostkamp/local/lib/python2.5/re.py", line 180, in
compile
return _compile(pattern, flags)
File "/export/home/ostkamp/local/lib/python2.5/re.py", line 231, in
_compile
p = sre_compile.compile(pattern, flags)
File "/export/home/ostkamp/local/lib/python2.5/sre_compile.py", line
530, in compile
groupindex, indexgroup
OverflowError: regular expression code size limit exceeded
This is apparently caused by some code in Modules/_sre.c and
Modules/sre.h as follows:
self->code[i] = (SRE_CODE) value;
if ((unsigned long) self->code[i] != value) {
PyErr_SetString(PyExc_OverflowError,
"regular expression code size limit exceeded");
break;
}
An 'unsigned int' value is unnecessarily squeezed into an 'unsigned
short' field defined in sre.h:
#ifdef Py_UNICODE_WIDE
#define SRE_CODE Py_UCS4
#else
#define SRE_CODE unsigned short
#endif
On all systems I'm working on (SuSE Linux SLES 9, Solaris 8 etc.) the
else case of the ifdef applies which chooses 'unsigned short'.
I don't understand the relationship between 'unicode' and what is
apparently the size of the regular expression stack here.
Some experiments have shown that changing the 'unsigned short' to
'unsigned long' and rebuilding Python fixes the problem.
Here is a test program to reproduce the error:
#!/usr/bin/env python
import re, random, sys
def randhexstring():
return "".join(["%04x" % random.randint(0, 0x) for x in range(20)])
pats = [randhexstring() for x in range(1000)]
def rematch(pats):
pat = '(?:%s)' % '|'.join(pats)
return re.compile(pat).match
m = rematch(pats)
count = 0
for s in pats * 100:
if m(s):
count += 1
print count
Regards
Guido
--
components: Regular Expressions
messages: 55885
nosy: ostkamp
severity: normal
status: open
title: Medium size regexp crashes python
type: crash
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1160>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46970] dataclass(slots=True) incompatible with __init_subclass__
New submission from Guido Imperiale : Related to #46382 A class decorated with dataclass(slots=True) can't pass any parameters to the __init_subclass__ method of its parent class. from dataclasses import dataclass class A: __slots__ = () def __init_subclass__(cls, msg): print(msg) @dataclass(slots=True) class B(A, msg="Hello world!"): pass File "lib/python3.10/dataclasses.py", line 1145, in _add_slots cls = type(cls)(cls.__name__, cls.__bases__, cls_dict) TypeError: A.__init_subclass__() missing 1 required positional argument: 'msg' -- components: Library (Lib) messages: 414822 nosy: crusaderky priority: normal severity: normal status: open title: dataclass(slots=True) incompatible with __init_subclass__ versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46970] dataclass(slots=True) incompatible with __init_subclass__
Change by Guido Imperiale : -- nosy: +eric.smith ___ Python tracker <https://bugs.python.org/issue46970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46970] dataclass(slots=True) incompatible with __init_subclass__
Change by Guido Imperiale : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue46970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38105] hash collision when hash(x) == -2 causes many calls to __eq__
New submission from Guido Imperiale :
Take two objects where hash(a) == hash(b) == -2 exactly, but a != b,
When they are inserted in a dict or set, the __eq__ method is invoked a
whopping 13 times.
Does this have something to do with the special case of hash(-1) = -2?
class C:
def __init__(self, x, h):
self.x = x
self.h = h
def __eq__(self, other):
print(f"{self}.__eq__({other})")
return self.x == other.x
def __hash__(self):
print(f"{self}.__hash__")
return self.h
def __repr__(self):
return f"C({self.x, self.h})"
>>> {C(1, -2), C(2, -2)}
C((1, -2)).__hash__
C((2, -2)).__hash__
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
C((1, -2)).__eq__(C((2, -2)))
{C((1, -2)), C((2, -2))}
>>> {C(1, -3), C(1, -3)}
C((1, -3)).__hash__
C((1, -3)).__hash__
C((1, -3)).__eq__(C((1, -3)))
{C((1, -3))}
>>> {C(1, -1), C(1, -1)}
C((1, -1)).__hash__
C((1, -1)).__hash__
C((1, -1)).__eq__(C((1, -1)))
>>> {C(1, -2), C(1, -2)}
C((1, -2)).__hash__
C((1, -2)).__hash__
C((1, -2)).__eq__(C((1, -2)))
{C((1, -2))}
--
messages: 351798
nosy: crusaderky
priority: normal
severity: normal
status: open
title: hash collision when hash(x) == -2 causes many calls to __eq__
type: performance
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue38105>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38105] hash collision when hash(x) == -2 causes many calls to __eq__
Guido Imperiale added the comment:
Forgot a counter-example:
{C(1, 0), C(2, 0)}
C((1, 0)).__hash__
C((2, 0)).__hash__
C((1, 0)).__eq__(C((2, 0)))
{C((1, 0)), C((2, 0))}
--
___
Python tracker
<https://bugs.python.org/issue38105>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38105] hash collision when hash(x) == -2 causes many calls to __eq__
Guido Imperiale added the comment:
Of course, the chances that in real life a custom object will have hash == -2
are very small. Different story however is for the actual numbers -1 and -2:
In [2]: %timeit {-1, -3}
64.2 ns ± 1.41 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
In [3]: %timeit {-1, -2}
238 ns ± 5.64 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
--
___
Python tracker
<https://bugs.python.org/issue38105>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38214] __reduce__ API specs for objects with __slots__
New submission from Guido Imperiale :
The documentation for the pickle module states, about the 3rd element of the
tuple returned by __reduce__:
Optionally, the object’s state, which will be passed to the object’s
__setstate__() method as previously described. If the object has no such method
then, the value must be a dictionary and it will be added to the object’s
__dict__ attribute.
This doesn't seem correct to me. It should instead read:
Optionally, the object’s state, which will be passed to the object’s
__setstate__() method as previously described. If the object has no such
method, then the value must be:
- for objects with only __dict__, a dictionary which will be used to update the
object’s __dict__ attribute.
- for objects with only __slots__, a tuple of (None, {<__slots__ key>: ,
...})
- for objects with both __dict__ and __slots__, a tuple of ({<__dict__ key>:
, ...}, {<__slots__ key>: , ...})
--
assignee: docs@python
components: Documentation
messages: 352728
nosy: crusaderky, docs@python
priority: normal
severity: normal
status: open
title: __reduce__ API specs for objects with __slots__
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38214>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45589] webbrowser does not handle opens under Windows WSL properly
New submission from Guido F : The 'webbrowser' module throws warnings and bad RC codes when running under Windows Subsystem for Linux (WSL). This causes libraries that depend on the 'webbrowser' module to mistakenly assume there's been an error opening a URL. An example of this behaviour can be observed running `jupyter-lab` under WSL. Steps to reproduce: 1. Run Ubuntu (for example) under Windows WSL. 2. `python -m webbrowser https://www.python.org` Expected result: The wesite opens. Actual result: The website opens but produces a `No valid TTY` message, which also yields a non-zero return code. I have a patch for this bug that inspects the kernel version (platform.uname) and detects WSL. This is a similar solution that other projects have implemented to tackle this problem. For example, the fish shell project: https://github.com/fish-shell/fish-shell/blob/0e06a53dff5e198c4fcefb6419a53cf1267231a1/share/functions/help.fish#L83. -- components: Windows messages: 404896 nosy: guido.fioravantti, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: webbrowser does not handle opens under Windows WSL properly type: enhancement ___ Python tracker <https://bugs.python.org/issue45589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45589] webbrowser does not handle opens under Windows WSL properly
Guido F added the comment: My code patch uses ‘wslview’, which is a binary that is injected into every WSL distro and forwards file open commands to windows. I detect WSL inspecting the kernel version, which includes WSL tagging. On Tue, Nov 2, 2021 at 3:05 PM Steve Dower wrote: > > Steve Dower added the comment: > > We don't formally support it yet. We probably need somebody to develop > expertise in the emulation layer so that they can work with the Linux > distro experts to make sure their distros are doing things properly. > > It has no relation at all to our Windows support (right now) - all > versions of Python running in WSL 100% believe they are running on > whichever Linux distro the user is running. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue45589> > ___ > -- ___ Python tracker <https://bugs.python.org/issue45589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45589] webbrowser does not handle opens under Windows WSL properly
Guido F added the comment: Understood, my mistake. I wonder if explorer.exe or any other general purpose open command is guaranteed to be available in all WSL distros. There’s also a consideration to be made on WSL1 vs WSL2 (only v2 ships an actual Linux kernel). For detection, there’re some other projects that have done this for some time. Not sure they’re up to python-core standards, but I put an example for the fish shell in my original description. Might be worth looking into. On Tue, Nov 2, 2021 at 3:28 PM Steve Dower wrote: > > Steve Dower added the comment: > > FWIW, I don't have wslview in the Debian distro I'm currently using. It > does have wslpath though. > > Consistent detection and integration throughout CPython's standard > library (unless we believe we need special build options too) is > probably worth a python-dev discussion. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue45589> > ___ > -- ___ Python tracker <https://bugs.python.org/issue45589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38854] Decorator breaks inspect.getsource
New submission from Guido Imperiale :
Python 3.7.5 and 3.8.0
A decorator causes inspect.getsource() to return clipped output:
from collections import defaultdict
from functools import wraps
import inspect
def foo(*args):
def decorator(func):
@wraps(func)
def wrapper():
pass
return wrapper
return decorator
@foo(dict(), defaultdict(lambda: 1))
def f():
pass
print(inspect.getsource(f))
Output:
@foo(dict(), defaultdict(lambda: 1))
Expected output:
@foo(dict(), defaultdict(lambda: 1))
def f():
pass
These changes to the decorator parameters cause the problem to disappear:
- @foo({}, defaultdict(lambda: 1))
- @foo(dict(), defaultdict(list))
--
messages: 356993
nosy: crusaderky
priority: normal
severity: normal
status: open
title: Decorator breaks inspect.getsource
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue38854>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs docs
New submission from Guido Imperiale : (1) In the documentation for loads(), the name for the first argument of loads is 'bytes_object'. The actual signature, both in pickle.py and _pickle.c, it is instead 'data'. (2) In the documentation and in pickle.py, the default value for the 'buffers' parameter is None. However, in _pickle.c, it is an empty tuple (); this is also reflected by running the interpreter: In [1]: inspect.signature(pickle.loads).parameters['buffers'] Out[1]: Thanks to @hauntsaninja for spotting these in https://github.com/python/typeshed/pull/3636 -- assignee: docs@python components: Documentation, Library (Lib) messages: 360569 nosy: crusaderky, docs@python priority: normal severity: normal status: open title: pickle: inconsistent arguments pickle.py vs _pickle.c vs docs versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14031] logging module cannot format str.format log messages
New submission from Guido Kollerie :
When logging messages with variable data one typically writes:
username = 'Guido'
logging.info('User %s logged in', username)
However Python 3 has support str.format (PEP 3101). If one has adopted
str.format for formatting strings in Python 3 code one should also be able to
write the above as:
logging.info('User {} logged in', username)
However this currently is not supported. For backwards compatibility,% style
logging should remain the default. However when a logger is configured using:
import logging
logging.basicConfig(style='{', format='{levelname}:{message}')
all subsequent calls to logging.debug, logging.info, logging.warning,
logging.error, logging.critical, logging.exception and logging.log should use
str.format for formatting.
--
messages: 153481
nosy: gkoller
priority: normal
severity: normal
status: open
title: logging module cannot format str.format log messages
type: enhancement
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue14031>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14031] logging module cannot format str.format log messages
Guido Kollerie added the comment:
I see, could this be made to work if I explicitly request a logger instead?:
logger = logging.getLogger('my_logger', style='{')
logger.info('User {} logged in', username)
Maybe even for the root logger:
root_logger = logging.getLogger(style='{')
root_logger.info('User {} logged in', username)
--
___
Python tracker
<http://bugs.python.org/issue14031>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36456] task.cancel unbound recursion
Change by Guido Imperiale : -- nosy: +crusaderky ___ Python tracker <https://bugs.python.org/issue36456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37461] email.parser.Parser hang
New submission from Guido Vranken : The following will hang, and consume a large amount of memory: from email.parser import BytesParser, Parser from email.policy import default payload = "".join(chr(c) for c in [0x43, 0x6f, 0x6e, 0x74, 0x65, 0x6e, 0x74, 0x2d, 0x54, 0x79, 0x70, 0x65, 0x3a, 0x78, 0x3b, 0x61, 0x72, 0x1b, 0x2a, 0x3d, 0x22, 0x73, 0x4f, 0x27, 0x23, 0x61, 0xff, 0xff, 0x27, 0x5c, 0x22]) Parser(policy=default).parsestr(payload) -- components: email messages: 346953 nosy: Guido, barry, r.david.murray priority: normal severity: normal status: open title: email.parser.Parser hang type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29505] Submit the re, json, & csv modules to oss-fuzz testing
Guido Vranken added the comment: Hi, I've built a generic Python fuzzer and submitted it to OSS-Fuzz. It works by implementing a "def FuzzerRunOne(FuzzerInput):" function in Python in which some arbitrary code is run based on FuzzerInput, which is a bytes object. This is a more versatile solution than the current re, json, csv fuzzers as it requires no custom C code and adding more fuzzing targets is as easy as writing a new harness in Python and adding a build rule. Code coverage is measured at both the CPython level (*.c) and the Python level (*.py). CPython is compiled with AddressSanitizer. What this means is that both CPython memory bugs and Python library bugs (excessive memory consumption, hangs, slowdowns, unexpected exceptions) are expected to transpire. You can see my current set of fuzzers here: https://github.com/guidovranken/python-library-fuzzers The PR to OSS-Fuzz is https://github.com/google/oss-fuzz/pull/2567 Currently, the only Python maintainer who will be receiving automated bug reports is gpshead. Are there any other developers who normally process Python security bug reports and would like to receive notifications? Feel free to respond directly in the OSS-Fuzz PR thread. ------ nosy: +Guido ___ Python tracker <https://bugs.python.org/issue29505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37461] email.parser.Parser hang
Guido Vranken added the comment: I used fuzzing to find this bug. After applying your patch, the infinite loop is gone and it cannot find any other bugs of this nature. -- ___ Python tracker <https://bugs.python.org/issue37461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17183] Small enhancements to Lib/_markupbase.py
New submission from Guido Reina:
In the file: Lib/_markupbase.py, function: "_parse_doctype_element" there is:
if '>' in rawdata[j:]:
return rawdata.find(">", j) + 1
rawdata[j:] is being scanned twice.
It would be better to do:
pos = rawdata.find(">", j)
if pos != -1:
return pos + 1
Same thing in the function: "_parse_doctype_attlist":
if ")" in rawdata[j:]:
j = rawdata.find(")", j) + 1
else:
return -1
It would be better to do:
pos = rawdata.find(")", j)
if pos != -1:
j = pos + 1
else:
return -1
--
messages: 181903
nosy: guido
priority: normal
severity: normal
status: open
title: Small enhancements to Lib/_markupbase.py
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue17183>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17183] Small enhancements to Lib/_markupbase.py
Guido Reina added the comment: I am attaching a .tgz file with the tests I have performed. The .tgz file contains also a README.txt file with more detailed information. I have done the following test: The script loads the HTML file 'search.html' in 'rawdata' and searches '>' in a loop from the position 'i', being i in: range(len(rawdata)). with the three variants: "in" + "find" (test1.py), "find" (test2.py), "index" (test3.py). Result: Script First run Second run Third run - test1.py2.332.322.33 test2.py0.750.740.76 test3.py0.750.740.74 I don't know if the test is representative and whether it helps. If you think that the test could be improved/changed, just let me know, I will be happy to help. -- Added file: http://bugs.python.org/file29084/test.tgz ___ Python tracker <http://bugs.python.org/issue17183> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client
New submission from Guido Vranken:
Proof of concept:
# Script for Python 2
import urllib2
opener = urllib2.build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0' + chr(0x0A) + "Location:
header injection")]
response = opener.open("http://localhost:";)
# Data sent is:
"""
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost:
Connection: close
User-Agent: Mozilla/5.0
Location: header injection
"""
# End of script
# Python 3
from urllib.request import urlopen, build_opener
opener = build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0' + chr(0x0A) + "Location:
header injection")]
opener.open("http://localhost:";)
# Data sent is:
"""
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost:
Connection: close
User-Agent: Mozilla/5.0
Location: header injection
"""
# End of script
It is the responsibility of the developer leveraging Python and its HTTP client
libraries to ensure that their (web) application acts in accordance to official
HTTP specifications and that no threats to security will arise from their code.
However, newlines inside headers are arguably a special case of breaking the
conformity with RFC's in regard to the allowed character set. No illegal
character used inside a HTTP header is likely to have a compromising side
effect on back-end clients and servers and the integrity of their
communication, as a result of the leniency of most web servers. However, a
newline character (0x0A) embedded in a HTTP header invariably has the semantic
consequence of denoting the start of an additional header line. To put it
differently, not sanitizing headers in complete accordance to RFC's could be
seen as as virtue in that it gives the programmer a maximum amount of freedom,
without having to trade it for any likely or severe security ramifications, so
that they may use illegal characters in testing environments and environments
that are outlined by an expliticly less strict interpretation of the HTTP
protocol. Newlines are special in that they enable anyone who is able to
influence the header
content, to, in effect, perform additional invocations to add_header().
In issue 17322 ( http://bugs.python.org/issue17322 ) there is some discussion
as to the general compliance to RFC's by the HTTP client libraries. I'd like to
opt to begin with prohibiting newline characters to be present in HTTP headers.
Although this issue is not a "hard vulnerability" such as a buffer overflow, it
does translate to a potentially equal level of severity when considered from
the perspective of a web-enabled application, for which purpose the HTTP
libraries are typically used for. Lack of input validation on the application
developer's end will faciliate header injections, for example if user-supplied
data will end up as cookie content verbatim.
Adding this proposed additional layer of validation inside Python minimizes the
likelihood of a successful header injection while functionality is not notably
affected.
I'm inclined to add this validation to putheader() in the 'http' module rather
than in urllib, as this will secure all invocations to 'http' regardless of
intermediate libraries such as urllib.
Included is a patch for the latest checkout of the default branch that will
cause CannotSendHeader() to be raised if a newline character is detected in
either a header name or its value. Aside from detecting "\n", it also breaks on
"\r" as their respective implications can be similar. Feel free to adjust,
rewrite and transpose this to other branches where you feel this is appropriate.
Guido Vranken
Intelworks
--
components: Library (Lib)
files: disable_http_header_injection.patch
keywords: patch
messages: 231590
nosy: Guido
priority: normal
severity: normal
status: open
title: HTTP header injection in urrlib2/urllib/httplib/http.client
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37264/disable_http_header_injection.patch
___
Python tracker
<http://bugs.python.org/issue22928>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Guido Vranken added the comment: Serhiy Storchaka: good call on changing my 'n += (width + precision) < 20 ? 20 : (width + precision);' into 'if (width < precision) width = precision;', I didn't realize that sprintf's space requirement entails using the largest of the two instead of adding the two together. I noticed the apparently pointless width calculation in 'step 1' but decided not to touch it -- good that it's removed now though. I will start doing more debugging based on this new patch now to ensure that the bug is gone now. On a more design-related note, for the sake of readability and stability, I'd personally opt for implementing toned-down custom sprintf-like function that does exactly what it needs to do and nothing more, since a function like this one requires perfect alignment with the underlying sprintf() in terms of functionality, at the possible expense of stability and integrity issues like we see here. For instance, width and precision are currently overflowable, resulting in either a minus sign appearing in the resulant format string given to sprintf() (width and precision are signed integers), or completely overflowing it (ie. (uint64_t)18446744073709551617 == 1 ). Considering the latter example, how do we know sprintf uses the same logic? Guido -- nosy: +Guido ___ Python tracker <http://bugs.python.org/issue23055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23055] PyUnicode_FromFormatV crasher
Guido Vranken added the comment: I'd also like to add that, although I agree with Guido van Rossum that the likelihood of even triggering this bug in a general programming context is low, there are two buffer overflows at play here (one stack-based and one heap-based), and given an adversary's control over the format and vargs parameters, I'd there is a reasonable likelihood of exploiting it to execute arbitrary code, since the one controlling the parameters has some control as to which bytes end up where outside buffer boundaries. -- ___ Python tracker <http://bugs.python.org/issue23055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23130] Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem
New submission from Guido Vranken: Tools/scripts/ftpmirror.py does not guard against arbitrary path constructions, and, given a connection to a malicious FTP server (or a man in the middle attack), it is possible that any file on the client's filesystem gets overwritten. Ie,. if we suppose that ftpmirror.py is run from a "base directory" /home/xxx/yyy, file creations can occur outside this base directory, such as in /tmp, /etc, /var, just to give some examples. I've constructed a partial proof of concept FTP server that demonstrates directory and file creation outside the base directory (the directory the client script was launched from). I understand that most of the files in Tools/scripts/ are legacy applications that have long been deprecated. However, if the maintainers think these applications should be safe nonetheless, I'll be happy to construct and submit a patch that will remediate this issue. Guido Vranken Intelworks -- components: Demos and Tools messages: 233189 nosy: Guido priority: normal severity: normal status: open title: Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem type: security versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue23130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow
New submission from Guido Vranken:
The vulnerability described here is exceedingly difficult to exploit, since
there is no straight-forward way an "attacker" (someone who controls a Python
script contents but not other values such as system environment variables), can
control a relevant parameter to the vulnerable function (_Py_char2wchar in
Python/fileutils.c). It is, however, important that it is remediated since
unawareness of this vulnerability may cause an unsuspecting author to establish
a link between user and the function parameter in future versions of Python.
Like I said, the vulnerability is caused by code in the _Py_char2wchar
function. Indirectly this function is accessed through
Objects/unicodeobject.c:PyUnicode_DecodeLocaleAndSize(),
PyUnicode_DecodeFSDefaultAndSize(), PyUnicode_DecodeLocale, and some other
functions.
As far as I know this can only be exploited on 32-bit architectures (whose
overflow threshold of its registers is 2**32). The following description sets
out from the latest Python 3.4 code retrieved from
https://hg.python.org/cpython .
The problem lies in the computation of size of the buffer that will hold the
wide char version of the input string:
--
Python/fileutils.c
--
296 #ifdef HAVE_BROKEN_MBSTOWCS
297 /* Some platforms have a broken implementation of
298 * mbstowcs which does not count the characters that
299 * would result from conversion. Use an upper bound.
300 */
301 argsize = strlen(arg);
302 #else
303 argsize = mbstowcs(NULL, arg, 0);
304 #endif
...
...
306 res = (wchar_t *)PyMem_RawMalloc((argsize+1)*sizeof(wchar_t));
and:
331 argsize = strlen(arg) + 1;
332 res = (wchar_t*)PyMem_RawMalloc(argsize*sizeof(wchar_t));
Both invocations to PyMem_RawMalloc are not preceded by code that asserts no
overflow will occur as a result of multiplication of the length of 'arg' by
sizeof(wchar_t), which is typically 4 bytes. It follows that on a 32-bit
architecture, it is possible cause an internal overflow to occur through the
supplication of a string whose size is >= ((2**32)-1) / 4, which is 1 gigabyte.
The supplication of a 1 GB (minus one byte) string will therefore result in a
value of 0 being passed to PyMem_RawMalloc, because:
argsize = 1024*1024*1024-1
malloc_argument = ((argsize+1) * 4
print malloc_argument & 0x
# prints '0'
Effectively this will result in an allocation of exactly 1 byte, since a
parameter of 0 is automatically adjusted to 1 by the underlying
_PyMem_RawMalloc():
--
Objects/obmalloc.c
--
51 static void *
52 _PyMem_RawMalloc(void *ctx, size_t size)
53 {
54 /* PyMem_Malloc(0) means malloc(1). Some systems would return NULL
55for malloc(0), which would be treated as an error. Some platforms
would
56return a pointer with no memory behind it, which would break
pymalloc.
57To solve these problems, allocate an extra byte. */
58 if (size == 0)
59 size = 1;
60 return malloc(size);
61 }
Once the memory has been allocated, mbstowcs() is invoked:
--
Python/fileutils.c
--
306 res = (wchar_t *)PyMem_RawMalloc((argsize+1)*sizeof(wchar_t));
307 if (!res)
308 goto oom;
309 count = mbstowcs(res, arg, argsize+1);
In my test setup (latest 32 bit Debian), mbstowcs returns '0', meaning no bytes
were written to 'res'.
Then, 'res' is iterated over and the iteration is halted as soon as a
null-wchar or a wchar which is a surrogate:
--
Python/fileutils.c
--
310 if (count != (size_t)-1) {
311 wchar_t *tmp;
312 /* Only use the result if it contains no
313surrogate characters. */
314 for (tmp = res; *tmp != 0 &&
315 !Py_UNICODE_IS_SURROGATE(*tmp); tmp++)
316 ;
317 if (*tmp == 0) {
318 if (size != NULL)
319 *size = count;
320 return res;
321 }
322 }
323 PyMem_RawFree(res);
Py_UNICODE_IS_SURROGATE is defined as follows:
--
Include/unicodeobject.h
--
183 #define Py_UNICODE_IS_SURROGATE(ch) (0xD800 <= (ch) && (ch) <= 0xDFFF)
In the iteration over 'res', control is transferred back to the invoker of
_Py_char2wchar() if a null-wchar is encountered first. If, however, a wchar
that does satisfies the expression in Py_UNICODE_IS_SURROGATE() is encountered
first, *tmp is not null and thus the conditional code on lines 318-320 is
skipped.
The space that 'res' points to is unintialized. Uninitialized, however, does
not not entail randomness in this case. If an attacker has sufficient freedom
to manipulate the contents of the process memory prior to calling
_Py_char2wchar() in order to scatter it with values that sa
[issue26156] Bad name into power operator syntax
Guido Treutwein added the comment: Yurys answer and resolution misses the point. Nobody complained about the await operator. Fact is, that in the _power_ operator (chapter 6.5) as base specification now "await" is given. This is likely to be an inadvertent copy of the previous chapter, makes no sense here and should probably be replaced by "u_expr" or similar. ------ nosy: +Guido Treutwein ___ Python tracker <http://bugs.python.org/issue26156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26156] Bad name into power operator syntax
Guido Treutwein added the comment: I'm with David here, in that a change would improve ease of comprehension: I still find it strange, that the grammar symbol has the same name as the keyword (or in the proposed version keyword+'expr'), which is never done on more widely used levels. I would have expected something like 'coroutine_suspension', which reflects what it is and not which keyword is required to state it. 2016-05-06 15:04 GMT+02:00 R. David Murray : > > R. David Murray added the comment: > > Sounds like it is a bit more than just confusion: given that power can be > used outside a coroutine but await can't, Serhiy's formulation would seem > to me to be more semantically correct, even if syntactically it is the same > as the current. > > I think it would regardless be better to replace 'await' with > 'await_expr', so +1 on that from me as well. > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue26156> > ___ > -- ___ Python tracker <http://bugs.python.org/issue26156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46066] [doc] TypedDict alternative definition syntax with keyword args is confusing
Guido van Rossum added the comment: This is not really just a doc issue then, is it? Maybe we should just deprecate the feature? -- ___ Python tracker <https://bugs.python.org/issue46066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46066] TypedDict alternative definition syntax with keyword args is confusing
Guido van Rossum added the comment: I recommend opening an issue here: https://github.com/python/typing/issues/new/choose -- ___ Python tracker <https://bugs.python.org/issue46066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46074] deepfreeze should rehash all strings upon reset
New submission from Guido van Rossum : In https://github.com/python/cpython/pull/30096#discussion_r768802144 it is pointed out that the hash seed can be changed if the interpreter is reset. To guard against this we need to force (re)calculation of all hash seeds in the generated code when the corresponding code object is retrieved. This can be done by adding extra code to the `_Py_get__toplevel()` functions. (Strings that are shared between code objects will have to be rehashed repeatedly -- no big deal.) -- components: Build messages: 408550 nosy: gvanrossum priority: normal severity: normal stage: test needed status: open title: deepfreeze should rehash all strings upon reset type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Guido van Rossum added the comment: Couldn't we just change the first occurrence of "central location" in the note to "a central location" and the second to "(different) central locations"? That would leave Steven's intention intact but satisfy those who read it as referring to *a single* central location. -- nosy: +gvanrossum resolution: rejected -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45292] Implement PEP 654: Exception Groups
Guido van Rossum added the comment: We should have a discussion here about improvements that Mark Shannon would like to see, in particular to do more work in the compiler instead of the interpreter. -- nosy: +Mark.Shannon, gvanrossum ___ Python tracker <https://bugs.python.org/issue45292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46074] deepfreeze should rehash all strings upon reset
Guido van Rossum added the comment: Never mind, this was based on incorrect information. See subsequent messages in the linked thread. -- resolution: -> not a bug stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
New submission from Guido van Rossum : I am trying to build under Visual Studio (the 2019 release) and I'm encountering the following weird issue. In the project file PCbuild\_freeze_module.vcxproj there's a command that runs the Tools\scripts\deepfreeze.py script to generate some code. The invocation is as follows: Apparently the PythonForBuild variable is unset, because this steps is trying to *open* the deepfreeze.py script using the default app for opening .py files, which in my case is VS Code. It seems that when using PCbuild\build.bat, PythonForBuild is set (on line 121) to %PYTHON%, which presumably points to some Python interpreter. But apparently when the build is driven by VS, this is not executed and now we're stuck. Is there someone with enough MSBUILD skills to help me fix this? -- components: Build, Windows messages: 408635 nosy: gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Build hangs under Visual Studio in deepfreeze stage type: compile error versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Change by Guido van Rossum : -- keywords: +patch pull_requests: +28346 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30127 ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Guido van Rossum added the comment: Great! I will leave it to Steven and Mark D to work out an acceptable solution. PS. Allen Downey is a computer scientist who has written at least one book about Python. -- ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45755] Specialized generic class does not return class attributes in dir
Guido van Rossum added the comment: I think a 3.10 backport would be appreciated. -- ___ Python tracker <https://bugs.python.org/issue45755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Guido van Rossum added the comment: I don't see a reason to go through the bootstrap python on Windows. It would increase the build time, which is already pretty slow. -- ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46090] C extensions can't swap out live frames anymore
Guido van Rossum added the comment: A thread without a frame looks like a natural end case when you consider the frames as a linked list. Could it be that exec()/eval() run in the current frame, and if there isn't a frame, they refuse to run? (Sorry, I don't recall anything more specific without going hunting through old code.) -- ___ Python tracker <https://bugs.python.org/issue46090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46148] Optimize pathlib
Guido van Rossum added the comment: I presume https://github.com/faster-cpython/ideas/discussions/194 is also relevant. -- ___ Python tracker <https://bugs.python.org/issue46148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45235] argparse does not preserve namespace with subparser defaults
Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue45235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46148] Optimize pathlib
Guido van Rossum added the comment: > Note: attrgetter could easily be made faster by migrating it to use > vectorcall. Sure, though code that *doesn't* use attrgetter is usually easier to read -- attrgetter is rare enough in my experience that I usually have to look it up. So making attrgetter unnecessary in most cases would also be welcome. (The exception is when you have many trivial pass-through properties, or when the attribute name is a variable to begin with.) -- ___ Python tracker <https://bugs.python.org/issue46148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Guido van Rossum added the comment: Yes, it is too late for 3.10 (but you can add it to typing_extensions). Also, PEP 585 is done, we don't update PEPs. Please do test with `from __future__ import annotations` -- you never know. When this was first proposed (https://github.com/python/typing/issues/985) there were worries about backwards compatibility. Given how common property is, we need to make sure there are no problems with that. Can you address that? I don't see it in the original thread. Also, since this requires type checkers to change, do we need a PEP? Finally. Please keep discussion in this bpo issue, don't have long discussions on the PR. (Honestly I think it's too soon for a PR given that we don't seem to have agreement in the typing tracker discussion.) -- ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple
Guido van Rossum added the comment: We managed to do this for 'with' so it should be possible here too, I'd think. The "committing" token would be the newline following the close parenthesis. Serhiy: the benefit is when you want to split it across two lines, e.g. assert (a_very_long_condition(), "A Very Long Message") I know you can do this using backslash, e.. assert a_very_long_condition(), \ "A Very Long Message" but there's a strong cultural rejection of backslash for line splitting (it's in PEP 8 and engrained in many people's brains) and it's just so natural to use parentheses -- they work for 'import', 'with', function calls, 'if', etc. -- ___ Python tracker <https://bugs.python.org/issue46167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple
Guido van Rossum added the comment:
I like the lookahead. We could also make the comma and the message mandatory
when inside parentheses:
| 'assert' '(' a=expression ',' b=expression [','] ')' &(NEWLINE | ';')
| 'assert' a=expression b=[',' z=expression { z }]
(And probably add an "invalid" rule to cover tuples with 0, 1, 3 or more
elements.)
--
___
Python tracker
<https://bugs.python.org/issue46167>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple
Guido van Rossum added the comment: You don’t have to use the new feature. But people expect it to work. -- ___ Python tracker <https://bugs.python.org/issue46167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45665] Problems caused by isinstance(list[int], type) returning True
Guido van Rossum added the comment: See https://github.com/python/mypy/issues/9773#issuecomment-1000975000. I may have talked myself into agreeing with Serhiy there! It does seem inconsistent that Any is not considered a type but list[int] is: >>> isinstance(list[int], type) True >>> import typing >>> isinstance(typing.Any, type) -- ___ Python tracker <https://bugs.python.org/issue45665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46170] Improving the error message when subclassing NewType
Guido van Rossum added the comment: Do you have evidence that people make this particular mistake often? And that the suggested solution is indeed what they should use? Why would you want to subclass UserId? Do we have examples of other error messages split across two lines like this? -- ___ Python tracker <https://bugs.python.org/issue46170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46170] Improving the error message when subclassing NewType
Guido van Rossum added the comment:
Weird, the docs you cite claims
# Also does not typecheck
ProUserId = NewType('ProUserId', UserId)
but when I try it, it works at runtime and passes mypy (even with --strict) and
also pyright.
So maybe those docs are incorrect? I can't find anything in PEP 484 about this.
In any case I'd drop the newline in the message -- other "Did you mean" errors
don't have those.
--
___
Python tracker
<https://bugs.python.org/issue46170>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34498] Python 3.7+ break on singledispatch_function.register(pseudo_type), which Python 3.6 accepted
Guido van Rossum added the comment: There's no point in lamenting the compatibility with Python 3.6, it's water under the bridge. Dispatching on types like list[int] or types generated by NewType is not realistic. Maybe the only thing left to do is to raise an error on registration when the type is e.g. list[int]? Currently that passes, but then attempting to dispatch on *anything* fails with TypeError: issubclass() argument 2 cannot be a parameterized generic -- nosy: +gvanrossum, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue34498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46191] Conflict between using annotations in singledispatch() and MyPy
Guido van Rossum added the comment: That mypy error is only reported with a certain mypy setting (--strict, or probably one of the specific settings that that turns on). We won't be supporting Sequence[Any] at runtime (because we only support actual types), but we should support Sequence, since that *is* an actual type (at least collections.abc.Sequence is). So IMO this is either a problem in mypy (though in that case probably in typeshed) or a situation for which the user should just silence mypy (it's not perfect and never claimed to be). But I think there's nothing for us to do in Python itself, so this bug should be closed. -- ___ Python tracker <https://bugs.python.org/issue46191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34498] Python 3.7+ break on singledispatch_function.register(pseudo_type), which Python 3.6 accepted
Guido van Rossum added the comment: Let's close this issue as "won't fix" then. The solution "use collections.abc.Sequence" makes sense. -- ___ Python tracker <https://bugs.python.org/issue34498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Guido van Rossum added the comment: Could you try with 3.10 and the stdlib typing.Annotated please? There might be changes (in the past a default of None automatically caused an Optional to be added, but we changed our minds.-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46191] Conflict between using annotations in singledispatch() and MyPy
Guido van Rossum added the comment: If we allow registering list[int] but give it the same meaning as registering plain list (at runtime), that would violate user expectations pretty strongly -- for the same reason why we don't allow isinstance(x, list[int]). If you want stronger checking inside the function you should probably do something like @foo.register def _(_a: list) -> ...: a: list[int] = _a ... That said I don't care enough about singledispatch to argue strongly. -- ___ Python tracker <https://bugs.python.org/issue46191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Guido van Rossum added the comment: Yes, we changed PEP 484 in https://github.com/python/peps/pull/689. So get_type_hints() should follow suit. -- ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1
Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue44394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: Let me have a look. May take a day, okay?-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: So if I understand the speed.python.org results correctly, the time to run `python -c pass` went way up, but the time for `python -S -c pass` did not go up significantly. Unfortunately the only machine I have access to is a Mac, and I cannot repro this result, using PGO/LTO. Could it be a Linux thing? Or due to something in the venv for pyperformance? Note that I am using a much simpler test script: Tools/scripts/startuptime.py. I have not yet succeeded in building and running pyperformance, mostly since the Python I build doesn't have SSL configured (I always forget the flag to use on my machine) and pyperformance insists on installing a bunch of stuff (including new versions of pip and setuptools, it seels). Can anyone repro the perf regression on their box? -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment:
Maybe it's Linux specific? I managed to run pyperformance and got this:
### python_startup ###
Mean +- std dev: 23.2 ms +- 0.8 ms -> 23.4 ms +- 1.2 ms: 1.01x slower
Not significant
Note, I am not dismissing the report -- in fact it looks quite bad. But I am
failing to reproduce it, which makes it harder to understand the root cause. :-(
Maybe we can create a microbenchmark for this that just parses a large amount
of code?
Anyway, here's a random thought about why this might have such a big impact.
Look at this snippet (found all over the parser.c file):
if (p->level++ == MAXSTACK) {
p->error_indicator = 1;
PyErr_NoMemory();
}
if (p->error_indicator) {
p->level--;
return NULL;
}
This is two "unlikely" branches in a row, and the first sets the variable
tested by the second. Maybe this causes the processor to stall?
Also, maybe it would be wiser to use ++X instead of X++? (Though a good
compiler would just change X++ == Y into ++X == Y+1.)
Anyway, without a way to reproduce, there's not much that can be done.
--
___
Python tracker
<https://bugs.python.org/issue46110>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: Maybe something unrelated changed on the benchmark machines? (Like installing a new version of pyperformance???) Though it happened across both benchmark machines. What configuration and flags are being used to run the benchmark suite on that machine? -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: I propose a test: revert the PR and see if speed.Python.org shows a speedup back to the previous number.-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46244] typing._TypeVarLike missing __slots__
Guido van Rossum added the comment: Confirmed about _TypeVarLike. Go ahead and make a PR. Do add a news blurb when requested. Please open separate issues for other such classes, each fix may need to be reviewed by a different expert. -- ___ Python tracker <https://bugs.python.org/issue46244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: I wrote a tiny script that calls compile() on raw bytes read from some source file, does this 100 times, and reports the total time. I tested the script with Lib/pydoc_data/topics.py (which happens to be the largest source file in the CPython repo, but mostly string literals) and with Lib/test/test_socket.py (the second-largest file). I built python.exe on a Mac with PGO/LTO, from "make clean", both before and after (at) PR 30177. For both files, the difference between the results is well in the noise caused by my machine (I don't have a systematic way to stop background jobs). But it's very clear that this PR cannot have been the cause of an 85% jump in the time taken by the python_startup benchmark in PyPerformance. For topics.py, the time was around 7.2 msec/compile; for test_socket.py, it was around 38. (I am not showing separate before/after numbers because the noise in my data really is embarrassing.) The compilation speed comes down to ~170,000 lines/sec on my machine (an Intel Mac from 2019; 2.6 GHz 6-Core Intel Core i7 running macOS Big Sur 11.6.1; it has clang 12.0.5). It must be something weird on the benchmark machines. I suspect that a new version of some package was installed in the venv shared by all the benchmarks (we are still using PyPerformance 1.0.2) and that affected something, perhaps through a .pth file? -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: "is very very unlike that there is no actual regression" I presume you meant "it is very very *likely* that there is no actual regression" This shouldn't hold up releases, but (having spent months trying to improve startup speed) I would still like to get to the bottom of the speed.python.org regression. -- priority: release blocker -> normal ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45665] Problems caused by isinstance(list[int], type) returning True
Guido van Rossum added the comment: So is it too late to change this? This went out with 3.10, Serhiy has argued it's a bugfix. -- ___ Python tracker <https://bugs.python.org/issue45665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45665] Problems caused by isinstance(list[int], type) returning True
Guido van Rossum added the comment: Okay, so it is probably here to stay. We could justify it (after the fact :-) by saying that you can instantiate list[int], but not Any. Are there exceptions to that? (I.e. are there other annotation types that have isinstance(X, type) return False but can be instantiated, or the other way around?) -- ___ Python tracker <https://bugs.python.org/issue45665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: I'm still wondering why speed.python.org showed such a slowdown, and how we can revert that. Here's a new theory. Thanks to an investigation I did together with Eric, I now suspect that the release of setuptools 60.0.0 on Dec 19 is a smoking gun. PyPerformance (re)installs the latest versions of pip and setuptools. Setuptools 60.0 makes a change in the file distutils-precedence.pth that causes it (by default) to import something called _distutils_hack and to call its add_shim() function. In previous setuptools this was off by default, but in 60.0 it switched to on. See https://github.com/pypa/setuptools/blob/main/CHANGES.rst#v6000 That add_shim() call in turn installs an extra entry in front of sys.meta_path, which does a bunch of extra work. See https://github.com/pypa/setuptools/blob/main/_distutils_hack/__init__.py Pablo, can we change the PyPerformance configuration or the script that runs it to set and export SETUPTOOLS_USE_DISTUTILS=stdlib, to see whether that affects perf at all? (Note that the code in distutils-precedence.pth is executed by site.py in addpackage().) -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: More data. On my Mac, with SETUPTOOLS_USE_DISTUTILS=stdlib, using -X importtime I see the following extra modules being imported: import time: 278 |278 | types import time: 112 |112 | _operator import time: 419 |531 | operator import time: 129 |129 | itertools import time: 325 |325 | keyword import time: 468 |468 | reprlib import time: 258 |258 | _collections import time: 978 | 2156 | collections import time:78 | 78 | _functools import time: 835 | 3068 | functools import time: 1359 | 5235 | enum import time: 138 |138 | _sre import time: 497 |497 | sre_constants import time: 528 | 1025 | sre_parse import time: 512 | 1674 | sre_compile import time: 109 |109 | _locale import time: 886 |886 | copyreg import time: 671 | 8574 | re import time: 471 |471 | warnings import time: 330 |801 | importlib import time: 906 | 10279 | _distutils_hack That's around 10 msec, so in the right ballpark. -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45665] Problems caused by isinstance(list[int], type) returning True
Guido van Rossum added the comment: I now agree with Serhiy's plan. We should execute ASAP so people get a chance to try this in the next alpha release. We will still allow instantiating e.g. list[int], right? -- ___ Python tracker <https://bugs.python.org/issue45665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Change by Guido van Rossum : -- title: FreeBSL buiildbots cannot compile Python -> FreeBSD buildbots cannot compile Python ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Guido van Rossum added the comment: Is this under control, or do you still need help with some part? (Are there two separate issues or not?)-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46263] FreeBSD buildbots cannot compile Python
Guido van Rossum added the comment: IIUC Steve is still on vacation, so we shouldn't wait for him to fix this. -- ___ Python tracker <https://bugs.python.org/issue46263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41370] PEP 585 and ForwardRef
Guido van Rossum added the comment:
Niklas, can you show a brief example showing the issue you're running into? Is
it just that list["Node"].__args__ is just ("Node",), not
(ForwardRef("Node"),)? Or is it more complex?
--
___
Python tracker
<https://bugs.python.org/issue41370>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45661] [meta] Freeze commonly used stdlib modules.
Guido van Rossum added the comment: Deep-freezing is definitely not a miracle cure. We should continue to trim or delay unneeded imports (like Christian just did for setuptools' _distutils_hack). What *would* be a miracle cure would be if we could deep-freeze the module contents after it has *executed*. But that is much harder in general, since two executions (even on the same platform) could result in different module contents (e.g. conditionally defining something based on environment contents). Instagram's Cinder has something that works for this, strict modules (https://github.com/facebookincubator/cinder#strict-modules). It is a complex system! But if we could do this it could really speed up a lot of imports tremendously. (Though still at the cost of binary size increase.) -- ___ Python tracker <https://bugs.python.org/issue45661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: To close the loop, setuptools 60.4.0 should fix this, see https://github.com/pypa/setuptools/pull/3009. -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46148] Optimize pathlib
Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker <https://bugs.python.org/issue46148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46110] compile("-"*3000000 + "4", '', mode) causes hard crash
Guido van Rossum added the comment: Yup. All better: https://speed.python.org/timeline/#/?exe=12&ben=python_startup&env=1&revs=50&equid=off&quarts=on&extr=on -- ___ Python tracker <https://bugs.python.org/issue46110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46333] ForwardRef.__eq__ does not respect module parameter
Change by Guido van Rossum : -- stage: -> needs patch ___ Python tracker <https://bugs.python.org/issue46333> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46333] ForwardRef.__eq__ does not respect module parameter
Guido van Rossum added the comment: Good catch. Do you want to submit a PR? I agree that the repr() could also be better (but please only show other values if they differ from the default). -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46333> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Guido van Rossum added the comment: Since the conclusion is that we can't do this without breaking backwards compatibility, should we just close this? Or is there still a compromise possible? -- ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41987] singledispatchmethod raises an error when relying on a forward declaration
Guido van Rossum added the comment: Thanks for the bisection. It's not surprising that that's the culprit, and in other situations that's the right thing to do. I'm not sure how to address this without breaking other stuff -- maybe leave the ForwardRef if evaluating it doesn't work? But that's likely to have other subtle side effects -- we still want simple typos (or other reasons why a reference is legitimately broken) to go unchecked. Maybe singledispatch can catch the error and fall back on looking at bare __annotations__? -- ___ Python tracker <https://bugs.python.org/issue41987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46244] typing._TypeVarLike missing __slots__
Guido van Rossum added the comment: Yes.-- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46346] New compilation warnings on Windows
New submission from Guido van Rossum : I am getting these warnings: C:\Users\gvanrossum\cpython\PC\_testconsole.c(70,38): warning C4013: '_Py_get_osfhandle' undefined; assuming extern returnin g int [C:\Users\gvanrossum\cpython\PCbuild\_testconsole.vcxproj] C:\Users\gvanrossum\cpython\PC\_testconsole.c(70,1): warning C4047: 'initializing': 'HANDLE' differs in levels of indirectio n from 'int' [C:\Users\gvanrossum\cpython\PCbuild\_testconsole.vcxproj] C:\Users\gvanrossum\cpython\Modules\_tkinter.c(144,37): warning C4013: '_Py_stat' undefined; assuming extern returning int [ C:\Users\gvanrossum\cpython\PCbuild\_tkinter.vcxproj] I noticed that GitHub also was flagging these in unrelated PRs. -- components: Build, Windows messages: 410320 nosy: gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: New compilation warnings on Windows versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Change by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46348] Modernize `test_typing`
Guido van Rossum added the comment: New changeset e2a9c8ef09cb7123d6b28852a323e6cc1f878b5b by Nikita Sobolev in branch 'main': bpo-46348: modernize `test_typing` (GH-30547) https://github.com/python/cpython/commit/e2a9c8ef09cb7123d6b28852a323e6cc1f878b5b -- ___ Python tracker <https://bugs.python.org/issue46348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46342] Make @final introspectable at runtime
Guido van Rossum added the comment: New changeset 0bbf30e2b910bc9c5899134ae9d73a8df968da35 by Jelle Zijlstra in branch 'main': bpo-46342: make @typing.final introspectable (GH-30530) https://github.com/python/cpython/commit/0bbf30e2b910bc9c5899134ae9d73a8df968da35 -- ___ Python tracker <https://bugs.python.org/issue46342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default
Guido van Rossum added the comment: New changeset 1de60155d5d01be2924e72fb68dd13d4fd00acd7 by Nikita Sobolev in branch 'main': bpo-46345: Add a test case for implicit `Optional` class attribute (GH-30535) https://github.com/python/cpython/commit/1de60155d5d01be2924e72fb68dd13d4fd00acd7 -- ___ Python tracker <https://bugs.python.org/issue46345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default
Guido van Rossum added the comment: Wasn’t the fix for it also backported? (Weird that the test wasn’t part of the fix.) -- ___ Python tracker <https://bugs.python.org/issue46345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46399] Addition of `mapping` attribute to dict views classes has inadvertently broken type-checkers
Guido van Rossum added the comment: Okay, PR welcome. (Though since this can only work for 3.11+, maybe typeshed could also be adjusted? For that you’d have to file a bug there.) -- ___ Python tracker <https://bugs.python.org/issue46399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
Guido van Rossum added the comment: [Meta: Why did adding a comment add all those people (back?) to the nosy list?] -- ___ Python tracker <https://bugs.python.org/issue12782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46399] Addition of `mapping` attribute to dict views classes has inadvertently broken type-checkers
Guido van Rossum added the comment: Probably. On Mon, Jan 17, 2022 at 02:14 Alex Waygood wrote: > > Alex Waygood added the comment: > > Do these changes warrant an entry in "What's New in 3.11"? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue46399> > ___ > -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46429] Merge all deepfrozen files into one
New submission from Guido van Rossum : This saves some space when strings are shared across deep-frozen module. Kumar measured this at around 0.2 Mbyte. See discussion https://github.com/faster-cpython/ideas/issues/218 -- ___ Python tracker <https://bugs.python.org/issue46429> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46399] Addition of `mapping` attribute to dict views classes has inadvertently broken type-checkers
Guido van Rossum added the comment: Given all this discussion I defer to Serhiy and Inada-San. On Wed, Jan 19, 2022 at 02:23 Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > I share concerns of Inada-san. I also think that keeping a status quo > (ignoring the mapping attribute in typing) is the lesser evil. I am not > sure that exposing this attribute was a good idea. We do not expose > attributes list and index for list iterators. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue46399> > ___ > -- --Guido (mobile) -- ___ Python tracker <https://bugs.python.org/issue46399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46437] Non-required `hasattr` checks in `test_typing`
Guido van Rossum added the comment: New changeset 263c0dd16017613c5ea2fbfc270be4de2b41b5ad by Nikita Sobolev in branch 'main': bpo-46437: remove useless `hasattr` from `test_typing` (#30704) https://github.com/python/cpython/commit/263c0dd16017613c5ea2fbfc270be4de2b41b5ad -- nosy: +gvanrossum ___ Python tracker <https://bugs.python.org/issue46437> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46441] Caret points to wrong line on 'return yield 42' in REPL
New submission from Guido van Rossum : This seems to happen in 3.11 in the REPL only. >>> def f(): ... print(0) ... return yield 42 File "", line 3 def f(): ^ SyntaxError: invalid syntax Note that running it from a file gives the expected output: PS C:\Users\gvanrossum\cpython> py -3.10 .\t.py File "C:\Users\gvanrossum\cpython\t.py", line 3 return yield 42 ^ SyntaxError: invalid syntax as does the 3.10 REPL: >>> def f(): ... print(0) ... return yield 42 File "", line 3 return yield 42 ^ SyntaxError: invalid syntax -- assignee: pablogsal components: Parser messages: 410988 nosy: gvanrossum, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Caret points to wrong line on 'return yield 42' in REPL versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46443] Deepfreeze use preallocated small ints
Guido van Rossum added the comment: New changeset 194ecc6d44adc1fb39a56ca696418368b69432ce by Kumar Aditya in branch 'main': bpo-46443: deepfreeze: use small ints and singleton zero bytes (GH-30715) https://github.com/python/cpython/commit/194ecc6d44adc1fb39a56ca696418368b69432ce -- ___ Python tracker <https://bugs.python.org/issue46443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46441] Caret points to wrong line on 'return yield 42' in REPL
Guido van Rossum added the comment: Thanks for the quick fix! -- ___ Python tracker <https://bugs.python.org/issue46441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46429] Merge all deepfrozen files into one
Guido van Rossum added the comment: New changeset ef3ef6fa43d5cca072eed2a66064e818de583be7 by Kumar Aditya in branch 'main': bpo-46429: Merge all deepfrozen files into one (GH-30572) https://github.com/python/cpython/commit/ef3ef6fa43d5cca072eed2a66064e818de583be7 -- ___ Python tracker <https://bugs.python.org/issue46429> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
