New submission from Florian Bruhin python@the-compiler.org:
Hey,
I just got the error message in the title when trying to run a script with
python.
You can find the coredump, stacktrace, and the scripts I ran at
http://the-compiler.org/tmp/pythoncrash/
The command line I ran:
python -u
New submission from Florian Bruhin:
The os.exec* functions seem to mangle arguments on Windows. So far I noticed
the supplied argv gets split on spaces, and double-quotes get stripped when not
escaped.
Example, on Windows 7:
platform.platform()
'Windows-7-6.1.7601-SP1'
os.execlp('python
Florian Bruhin added the comment:
I can't test this right now, but I'd guess you also have to escape a inside
an argument (with \ presumably), and a \ with \\. Maybe more, no idea.
Actually the documentation doesn't say anything about me _having_ to escape
anything, so I'd assume I don't
New submission from Florian Bruhin:
When faulthandler is used while sys.stderr is None (e.g. when using
pythonw.exe), a (IMHO) confusing exception is raised:
Traceback (most recent call last):
File test.py, line 7, in module
faulthandler.enable()
AttributeError
New submission from Florian Bruhin:
When adding something to a configparser instance which has a key beginning with
a comment char, it writes the data to a file without generating an error, and
when reading the file back obviously the data is different as it's a comment:
cp
Florian Bruhin added the comment:
I didn't test the patch (I don't have the toolchain set up to do so), but it
looks like this is indeed an exception which makes more sense to the developer.
When I saw the exception as it is now, I only discovered it's related to stderr
being None by finding
Florian Bruhin added the comment:
The thing is the developer is not necessarely the one controlling if sys.stderr
is None, sometimes the user is.
For example, see
https://docs.python.org/3.4/using/windows.html#executing-scripts-without-the-python-launcher
- an user might have decided to use
New submission from Florian Bruhin:
When there's an unraisable exception (e.g. in __del__), and there's an
exception in __repr__ as well, PyErr_WriteUnraisable returns after writing
Exception ignored in: immediately.
I'd expect it to fall back to the default __repr__ instead.
See
New submission from Florian Bruhin:
When using getpass.getpass() on Windows and typing a tilde (~) with a layout
with dead keys (e.g. Swiss German), one would typically type ~ to get a
single tilde.
However, this returns '\x00\x83~' with getpass. It seems this is what
msvcrt.getch() returns
Changes by Florian Bruhin python@the-compiler.org:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22836
___
___
Python-bugs
Changes by Florian Bruhin python@the-compiler.org:
--
nosy: +christian.heimes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22837
Florian Bruhin added the comment:
Maybe this is related: U+0083 is the no break here char:
http://www.fileformat.info/info/unicode/char/0083/index.htm
http://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_set
From wikipedia: Follows the graphic character that is not to be broken
New submission from Florian Bruhin:
https://docs.python.org/3/library/venv.html says:
If the target directory already exists an error will be raised, unless the
--clear or --upgrade option was provided.
However, that doesn't seem to be the case:
[florian@ginny ~]$ python --version
Python
New submission from Florian Bruhin:
logging.basicConfig uses **kwargs and does not validate them.
This caused me to shoot myself in the foot multiple times by passing logLevel
instead of level accidentally, and then trying to figure out why my messages
don't get logged.
--
messages
Changes by Florian Bruhin python@the-compiler.org:
--
nosy: +The Compiler
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7511
___
___
Python
New submission from Florian Bruhin:
I just accidentally passed a list (instead of unpacking it) to os.path.join. I
was surprised when it just returned the list unmodified:
os.path.join([1, 2, 3])
[1, 2, 3]
Looking at the source, it simply returns the first argument (path = a; ...;
return
Florian Bruhin added the comment:
Serhiy, I don't see a new patch added - did you forget to attach it or am I
missing something? :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23780
New submission from Florian Bruhin:
Trying to call a 32bit Python via subprocess from a 64bit one works as expected:
Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:16:31) [MSC v.1600 64
bit (AMD64)] on win32
[...]
subprocess.check_call([r'C:\Python34_x32\python.exe', '-c
Florian Bruhin added the comment:
That gives me Environment variable SYSTEMROOT not defined which would explain
the Fatal Python error I'm seeing.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24493
Florian Bruhin added the comment:
I've now updated to Python 3.4.3 and it's broken there as well.
I tried on two other Windows 8.1 machines (with Python 3.4.3 and 3.4.1
respectively), and I can't reproduce there either...
It works with shell=True indeed.
I wonder why this is only broken
Florian Bruhin added the comment:
Sorry I missed this - I can reproduce this on Windows 8.1, but not on Windows
7. I hope I'll be able to try another Windows 8.1 machine today.
SYSTEMROOT is definitely set in the original environment:
os.environ['SYSTEMROOT']
'C:\\Windows
Changes by Florian Bruhin python@the-compiler.org:
--
nosy: +The Compiler
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24294
___
___
Python
New submission from Florian Bruhin:
I just found this thanks to Hypothesis[1]:
>>> import re
>>> re.compile('(' * 500)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/re.py", line 224, in compile
Florian Bruhin added the comment:
I see how it's not possible to compile that pattern as it's using recursion - I
don't mind that.
However, I think this should be handled and re-raised as a re.error ("Exception
raised [...] when some other error occurs during compilation or matching.&
New submission from Florian Bruhin:
On Windows 8:
>>> fnmatch.fnmatch(r'foo\bar', 'foo/bar')
True
>>> fnmatch.fnmatchcase(r'foo\bar', 'foo/bar')
False
This is due to fnmatch calling os.path.normpath on the arguments (to get the
case-sensitivity of the filesystem), whic
Florian Bruhin added the comment:
At least with my WM, there is no concept of having floating windows when in
tiling mode, so I don't think that would be possible.
I also don't think there's a standard way to tell a window manager to not tile
windows.
What about opening a simple window
Changes by Florian Bruhin <python@the-compiler.org>:
--
nosy: -The-Compiler
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Florian Bruhin added the comment:
I just ran into this again - when trying to run `git` via subprocess with "env"
set, I got:
# Start the process
try:
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
#
Florian Bruhin added the comment:
> Sounds like there's something in the cwd that is making the difference (this
> being Windows which looks for things in the cwd always).
The cwd is an empty temporary directory. And that still wouldn't explain why
passing env=os.environ breaks it a
New submission from Florian Bruhin:
I can reproduce this with 3.4.3 and 3.5.0:
>>> import codecs
>>> codecs.escape_encode(b'')
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/bytesobject.c:3553: bad argument to internal function
--
Florian Bruhin added the comment:
I agree this would be useful. "assert themock.called" (or self.assertTrue)
works, but always trips me up.
--
nosy: +The Compiler
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Changes by Florian Bruhin <python@the-compiler.org>:
--
nosy: +michael.foord
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Florian Bruhin <python@the-compiler.org>:
--
nosy: +The Compiler, dstufft, vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Florian Bruhin added the comment:
I just got bitten by this again - is anything holding this back from being
merged (other than lack of review-manpower)?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Florian Bruhin added the comment:
FWIW, this also affects pytest users:
https://github.com/pytest-dev/pytest/issues/1217
--
nosy: +The Compiler
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Florian Bruhin <python@the-compiler.org>:
--
nosy: +The Compiler
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Florian Bruhin:
While faulthandler's output is already quite useful when dealing with crashes
in C libraries, it'd be much more useful when it could also show a low-level
C/C++ stack.
glibc has functions to do that:
https://www.gnu.org/software/libc/manual/html_node
Florian Bruhin added the comment:
Hmm, fair point. I thought I had seen this being used in a SEGV handler in some
other software I use, but I can't find that anymore - so either I was dreaming,
or they noticed it was problematic and removed it again.
I'm closing this then. My goal was to get
Florian Bruhin added the comment:
https://github.com/python/cpython/pull/1535 seems to be the correct PR, not
1634.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Florian Bruhin :
Since bpo-29651, the urllib.parse docs say:
> Unmatched square brackets in the netloc attribute will raise a ValueError.
However, when there are at least one [ and ], but they don't match, there's
somewhat inconsistent behavior:
>>> urllib.pa
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue37440>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue37428>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
pull_requests: +14782
pull_request: https://github.com/python/cpython/pull/15021
___
Python tracker
<https://bugs.python.org/issue15
Florian Bruhin added the comment:
I'm seeing the same in ranger and I'm currently trying to debug this - I'm still
not quite sure what I'm seeing as there seem to be various issues/weirdnesses
which overlap each other.
This strikes me as odd:
>>> import mimetypes
>>> mi
Florian Bruhin added the comment:
I now bisected this with the following script:
#!/bin/bash
git clean -dxf
./configure || exit 125
make -j2 || exit 125
output=$(./python -c "import mimetypes; mt = mimetypes.MimeTypes();
print(mt.guess_type('E01.mkv')[0])")
echo "$outp
Florian Bruhin added the comment:
Ah, I think I see what's happening now.
Before that commit, when doing "mt = mimetypes.MimeTypes()", its self.types_map
is populated as follows:
- Its __init__ method calls the mimetypes.init() function.
- That then reads all
Change by Florian Bruhin :
--
nosy: +r.david.murray
___
Python tracker
<https://bugs.python.org/issue38656>
___
___
Python-bugs-list mailing list
Unsubscribe:
Florian Bruhin added the comment:
Ah, I only saw dhess' comment after already submitting mine.
> By historical design, instantiating a MimeTypes class instance directly will
> not use host OS system mime type files.
Yet that wasn't what happened before that commit, and it'
New submission from Florian Bruhin :
A minor issue I just discovered today: When e.g. doing "python3 --foo", the
output is:
unknown option --foo
unknown option --foo
unknown option --foo
usage: /usr/bin/python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
With m
Florian Bruhin added the comment:
That was an insanely fast fix - thanks everyone! :)
--
___
Python tracker
<https://bugs.python.org/issue40527>
___
___
Pytho
Florian Bruhin added the comment:
Ah, also see https://bugs.python.org/issue21071#msg292409 where the same thing
was mentioned as part of another issue as well.
After some discussions in the Python IRC channel, I guess it's acceptable for
dicts to raise a ByteWarning here - after all
Florian Bruhin added the comment:
Taking the freedom of adding people involved in the `struct` module to the nosy
list.
--
nosy: +The Compiler, mark.dickinson, meador.inge
___
Python tracker
<https://bugs.python.org/issue41
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue40747>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue41909>
___
___
Python-bugs-list mailing list
Unsubscribe:
Florian Bruhin added the comment:
I wonder if I should request a CVE for this as well? Just to make sure the word
gets out to distributions/organizations/etc. running the Python testsuite,
given that we can't be sure it which contexts this happens (and as it could be
exploited by e.g
Florian Bruhin added the comment:
That assumption is false. For starters, distribution packagers do:
https://github.com/archlinux/svntogit-packages/blob/3fc85177e35d1ff9ab000950c5d1af9567730434/trunk/PKGBUILD#L72-L84
https://src.fedoraproject.org/rpms/python3.9/blob/master/f/python3.9.spec
Change by Florian Bruhin :
--
pull_requests: +21570
pull_request: https://github.com/python/cpython/pull/22575
___
Python tracker
<https://bugs.python.org/issue41
Florian Bruhin added the comment:
Thanks for the clarification - I wasn't aware those tests aren't run by default.
FWIW I found another place where a similar thing is done, though by chance it's
probably not exploitable - see GH-22575
Florian Bruhin added the comment:
> It is also not safe to pass data downloaded from untrusted source to eval().
To make matters worse, it's downloaded via HTTP (rather than HTTPS) - so anyone
who can mess with the network of a machine running the Python testsuite can run
arbitrary c
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue41836>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue25655>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue38488>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Florian Bruhin :
When shutil.get_terminal_size() is used in a PTY, the os.get_terminal_size()
call can return (0, 0).
With the pty script from
https://github.com/python/mypy/issues/8144#issue-537760245:
$ python3 t.py python3 -c 'import shutil; print
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue41154>
___
___
Python-bugs-list mailing list
Unsubscribe:
Florian Bruhin added the comment:
Just found another workaround for this in the wild, as part of the "rich"
library:
https://github.com/willmcgugan/rich/blob/v9.1.0/rich/console.py#L669-L672
--
___
Python tracker
<https://bu
New submission from Florian Bruhin :
Found mostly by accident:
>>> import email.headerregistry
>>> reg = email.headerregistry.HeaderRegistry()
>>> h = reg('Content-Disposition', 'inline; 0*²')
Traceback (most recent call last):
File "", line 1,
New submission from Florian Bruhin :
Consider this reproducer:
>>> import email.headerregistry
>>> reg = email.headerregistry.HeaderRegistry()
>>> parsed = reg('Content-Disposition', """attachment;
filename="foo-ae.html"; filenam
Florian Bruhin added the comment:
I think this has been fixed in Python 3.7+ via
https://github.com/python/cpython/pull/14375 - at least for a couple of types.
Comparing Python 3.6 with the current state, the following changed (which can
be used as an "override" dict befo
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue43248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Florian Bruhin added the comment:
Whoops, I was mistaken about Python 3.8 not being affected. I thought it
wouldn't be because importlib.resources.files was added in 3.9, but
zipfile.Path was added in 3.8.
With that in mind, I guess changing the behavior of 3.9 would be rather
confusing
New submission from Florian Bruhin :
When a package is installed as an egg, importlib.resources.files returns a
zipfile.Path rather than a pathlib.Path (maybe it returns other things too,
seeing that it's documented to return a importlib.abc.Traversable - I didn't
check).
However, those two
Florian Bruhin added the comment:
I suppose returning the string unchanged would work as well. However, "Errors
should never pass silently." :)
Perhaps that with a ignore_nameerror=True or switch or so would work?
--
___
Python track
New submission from Florian Bruhin :
Consider a file such as:
# from __future__ import annotations
from typing import TYPE_CHECKING, Union, get_type_hints
if TYPE_CHECKING:
import types
def fun(a: 'types.SimpleNamespace', b: Union[int, str]):
pass
print
Florian Bruhin added the comment:
This is not a bug. itertools.product returns an iterator:
https://docs.python.org/3/glossary.html#term-iterator
Quoting from there:
> [...] every iterator is also iterable and may be used in most places where
> other iterables are accepted. One n
Florian Bruhin added the comment:
Fair points.
As an aside, I'm also wondering how inspect.Parameter.annotation should
interact with the changes in Python 3.10? That used to be the canonical way (as
far as I'm aware) of getting a single argument's type annotation (other than
getting
Florian Bruhin added the comment:
Ah, I wasn't aware of that, thanks for the pointer! So what inspect does
internally is:
def _get_type_hints(func, **kwargs):
try:
return typing.get_type_hints(func, **kwargs)
except Exception:
# First, try to use
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue43355>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue40066>
___
___
Python-bugs-list mailing list
Unsubscribe:
Florian Bruhin added the comment:
I'm probably a bit late to the party as well, but as some additional datapoints:
- This broke the tests for my project and I ended up adding a wrapper to
stringify enums (since I actually prefer having the enum type in debug logs and
such):
https
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue43798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Florian Bruhin :
--
nosy: +The Compiler
___
Python tracker
<https://bugs.python.org/issue43540>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Florian Bruhin :
After upgrading to 3.10a5, calling logging.exception("test") results in:
--- Logging error ---
Traceback (most recent call last):
File "/usr/lib/python3.10/logging/__init__.py", line 1094, in emit
msg = self.forma
82 matches
Mail list logo
