Change by Gregory P. Smith :
--
components: +2to3 (2.x to 3.x conversion tool)
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issu
New submission from Gregory P. Smith :
Based on the PEP 617 acceptance thread on python-dev, lib2to3 is eventually
going to run into trouble parsing modern syntax a few releases from now.
It would be better off maintained outside of the standard library. It gets
used by a lot of things
Change by Gregory P. Smith :
--
assignee: -> gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue40313>
___
___
Python-bugs-list mailing list
Un
Gregory P. Smith added the comment:
raspbian failure https://buildbot.python.org/all/#/builders/645/builds/31
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue35
Gregory P. Smith added the comment:
Marking everything as immortal/eternal after you've loaded your common code &
data but before you do your forking is thenorm for this kind of serving system.
You already presumably have a defined lifetime for the processes so they'll
likely be set to
Gregory P. Smith added the comment:
Thanks for sharing! It's good to have a patch implementing for others who
might need it to try out.
We experimented with an implementation of this on CPython 2.7 that we called
Eternal Refcounts for YouTube many years ago. For the same reason (saving
Gregory P. Smith added the comment:
bad buildbot hardware. i've taken that bot offline.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
type: -> crash
___
Python tracker
<https://bugs.python
Gregory P. Smith added the comment:
While I did a general apt update on that worker, I suspect I may have knocked
the heatsink loose over the weekend while dealing with an upcoming bot sitting
behind it on the shelf. That'd explain why it is alternately crashing and
making mystery results
Gregory P. Smith added the comment:
PyBytesObject could become a struct that contains a single opaque internal
struct.
there is some code out there that references PyBytesObjects internals by field
name but my searches across a broad swath of code so far seem to suggest that
is so rare
Gregory P. Smith added the comment:
agreed, being opaque seems ideal.
--
___
Python tracker
<https://bugs.python.org/issue40120>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
Support for `:=` is in, are we still lacking `f(**not x)` support?
--
___
Python tracker
<https://bugs.python.org/issue36
Gregory P. Smith added the comment:
master/3.9 changeset:
https://github.com/python/cpython/commit/3c3aa4516c70753de06bb142b6793d01330fcf0f
3.8 changeset:
https://github.com/python/cpython/commit/1098671e4e5ec1513247f05598158eaa3428c5be
Gregory P. Smith added the comment:
New changeset 96c5f5a3a3fabf43e8114d0dbc30bed409da1ba6 by Tim Hatch in branch
'3.7':
[3.7] bpo-36541: lib2to3: Support named assignment expressions (GH-12702)
(GH-19317)
https://github.com/python/cpython/commit/96c5f5a3a3fabf43e8114d0dbc30bed409da1ba6
Gregory P. Smith added the comment:
updates:
- extern "C" is indeed really only about linking so it has no bearing.
What I'm hearing from talking to our C++ compiler team is unfortunately sad:
The C++ standard does not support flexible array member syntax on purpose
becaus
Gregory P. Smith added the comment:
Isn't the only actual way for a C .h file to be compatible with C++ via
extern "C" {
}
which all of our non-meta include files appear to have already?
--
___
Python tracker
<https://bugs.python.o
Change by Gregory P. Smith :
--
title: Undefined C behavior going beyond end of struct via a char[1]. ->
Undefined C behavior going beyond end of struct via a [1] arrays.
___
Python tracker
<https://bugs.python.org/issu
Change by Gregory P. Smith :
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.python.org/issue40120>
___
___
Python-bugs-list mai
Gregory P. Smith added the comment:
"""
The [1] thing is used in more places:
PyObject *f_localsplus[1]; in PyFrameObject
PyObject *ob_item[1]; in PyTupleObject
void *elements[1]; in asdl_seq and int elements[1];` in asdl_int_seq
digit ob_digit[1]; in PyLongObject
Py_ssi
Gregory P. Smith added the comment:
>From the PR comment thread (as I opened that first):
"""Well, there was no other choice in ISO C89 than using char ob_sval[1];, no?
Is char ob_sval[]; supported by the C compiler supported by CPython? Like
Visual Studio, GCC, clang
Change by Gregory P. Smith :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue40120>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gregory P. Smith :
--
keywords: +patch
pull_requests: +18592
pull_request: https://github.com/python/cpython/pull/19232
___
Python tracker
<https://bugs.python.org/issue40
New submission from Gregory P. Smith :
The correct C99 way to do this is using a char[]. PyBytesObject and unicode's
struct encoding_map both do this.
Unclear to me if we should backport this to earlier versions or not (because
PyBytesObject may be exposed?) Probably, but I also doubt
Gregory P. Smith added the comment:
marking as a 2.7 release blocker just to get benjamin's RM attention before the
final 2.7.
--
assignee: gregory.p.smith -> benjamin.peterson
nosy: +benjamin.peterson
priority: high -> release blocker
stage: resolved -> patch review
statu
Gregory P. Smith added the comment:
If anyone cares about 2.7, the *final* release is coming up in a few weeks.
They'll need to figure out what it looks like there and get a 2.7 PR reviewed
by the release manager.
--
resolution: -> fixed
stage: patch review -> resolved
Gregory P. Smith added the comment:
Thanks for the PR Ashwin!
--
assignee: -> gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue38576>
___
_
Gregory P. Smith added the comment:
New changeset 9165addc22d05e776a54319a8531ebd0b2fe01ef by Ashwin Ramaswami in
branch 'master':
bpo-38576: Disallow control characters in hostnames in http.client (GH-18995)
https://github.com/python/cpython/commit/9165addc22d05e776a54319a8531ebd0b2fe01ef
Gregory P. Smith added the comment:
I think those dict unpacking and merging options are sufficient that adding an
extra_env= parameter would merely complicate the already over complex API.
Thanks for the suggestions folks!
--
resolution: -> rejected
stage: -> resolved
New submission from Gregory P. Smith :
Recurring theme: The stdlib has the issue of DeprecationWarning being added to
APIs we are changing or removing a few versions in the future yet we perceive
that many people never actually bother to try checking their code for
deprecation warnings
Gregory P. Smith added the comment:
FYI - I updated the ubsan buildbot to clang 9 so this one shows up in there now:
/var/lib/buildbot/workers/clang-ubsan/3.x.gps-clang-ubsan.clang-ubsan/build/Modules/_struct.c:487:28:
runtime error: load of value 116, which is not a valid value for type
Gregory P. Smith added the comment:
If anyone else has a way to reproduce this issue, please run your tests with a
3.7/3.8/3.9 interpreter with the fix I committed applied and report back if you
still see this failure on that line.
I believe this to be fixed based on my own testing so I am
Gregory P. Smith added the comment:
Testing by changing list(sys.modules.items()) to sys.modules.copy().items()
internally with a large integration test that was reliably flaky on this line
before shows that the .copy().items() worked. The test is reliable again.
So I've gone ahead
Gregory P. Smith added the comment:
New changeset 85cf1d514b84dc9a4bcb40e20a12e1d82ff19f20 by Gregory P. Smith in
branch 'master':
bpo-13487: Use sys.modules.copy() in inspect.getmodule() for thread safety.
(GH-18786)
https://github.com/python/cpython/commit
Change by Gregory P. Smith :
--
pull_requests: +18143
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18786
___
Python tracker
<https://bugs.python.org/issu
Gregory P. Smith added the comment:
Serhiy: Why is dict.copy() not thread safe?
if what you say of list(dict) being safe, iterating over that and looking up
the keys would work. But all of this is entirely non-obvious to the reader of
the code. all of these _look_ like they should be safe
Gregory P. Smith added the comment:
fyi - we just had a test run into this (in a flaky manner - definitely a race
condition) at work:
```
...
for f in inspect.stack(context=0)
File "/inspect.py", line 1499, in stack
return getouterframes(sys._getframe(1), conte
Gregory P. Smith added the comment:
fwiw oss-fuzz also finds this on struct (via ubsan)
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20949
struct.unpack('?', ' ')
--
___
Python tracker
<https://bugs.python.org/issue39
Gregory P. Smith added the comment:
I _doubt_ there is code expecting the default year when unspecified to actually
be 1900.
Change that default to any old year with a leap year (1904?) and it'll still
(a) stand out as a special year that can be looked up should it wind up being
_used_
Gregory P. Smith added the comment:
While i don't think this was needed in 3.7 and 3.8, you kept the default
behavior the same so I don't think it is a problem.
If someone builds an interpreter with this configure flag, does it break
compatibility with anything that code may have started
Gregory P. Smith added the comment:
FYI - this appears to have caused a regression -
https://bugs.python.org/issue39776
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue32
Gregory P. Smith added the comment:
if anyone needs this on their older 3.6 or 3.5 trees, the 3.7/3.8 patch is a
trivial backport.
--
stage: patch review -> commit review
status: open -> closed
___
Python tracker
<https://bugs.p
Gregory P. Smith added the comment:
New changeset 7c64726ced3d6b5d04537386d6a9ca6d179c3be4 by Gregory P. Smith in
branch '3.7':
[3.7] bpo-39769: Fix compileall ddir for subpkgs. (GH-18676) (GH-18718)
(GH-18725)
https://github.com/python/cpython/commit
Change by Gregory P. Smith :
--
pull_requests: +18082
pull_request: https://github.com/python/cpython/pull/18725
___
Python tracker
<https://bugs.python.org/issue39
Gregory P. Smith added the comment:
New changeset ce720d3e0674d6ac6f1b950c20a89be4cfde7853 by Gregory P. Smith in
branch '3.8':
bpo-39769: Fix compileall ddir for subpkgs. (GH-18676) (GH-18718)
https://github.com/python/cpython/commit/ce720d3e0674d6ac6f1b950c20a89be4cfde7853
Change by Gregory P. Smith :
--
pull_requests: +18075
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/18718
___
Python tracker
<https://bugs.python.org/issu
Gregory P. Smith added the comment:
keeping this open while i investigate if fixing 3.8 and 3.7 is feasible. if
nothing else i'll try to add a note to the docs about the issue in 3.5-3.8 with
a code sample suggested workaround.
--
resolution: -> fixed
stage: patch review ->
Gregory P. Smith added the comment:
New changeset 02673352b5db6ca4d3dc804965facbedfe66425d by Gregory P. Smith in
branch 'master':
bpo-39769: Fix compileall ddir for subpkgs. (GH-18676)
https://github.com/python/cpython/commit/02673352b5db6ca4d3dc804965facbedfe66425d
Change by Gregory P. Smith :
--
title: Submit the re, json, & csv modules to oss-fuzz testing -> Submit the re,
json, csv, & struct modules to oss-fuzz testing
___
Python tracker
<https://bugs.python.
Gregory P. Smith added the comment:
the concept of a native _Bool seems fuzzy. the important thing for the struct
module is to consume sizeof _Bool bytes from the input stream. how those are
interpreted is up to the platform. So if the platform says a bool is 8 bytes
and it only ever
Change by Gregory P. Smith :
--
components: +Extension Modules
nosy: +gregory.p.smith
stage: -> needs patch
type: -> behavior
___
Python tracker
<https://bugs.python.org/i
Change by Gregory P. Smith :
--
keywords: +patch
pull_requests: +18036
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18676
___
Python tracker
<https://bugs.python.org/issu
Gregory P. Smith added the comment:
belated postmortem: if there had been tests against the filename encoded in the
pycs living in subdirs as generated by compile_dir, this regression would not
have happened.
--
___
Python tracker
<ht
Gregory P. Smith added the comment:
meaning this regression was introduced in 3.5.
--
versions: +Python 3.5
___
Python tracker
<https://bugs.python.org/issue39
Gregory P. Smith added the comment:
The regression was caused by the parallelization enhancement implementation
from https://bugs.python.org/issue16104
--
___
Python tracker
<https://bugs.python.org/issue39
Gregory P. Smith added the comment:
This caused a regression in behavior. compileall.compile_dir()'s ddir=
parameter no longer does the right thing for any subdirectories.
https://bugs.python.org/issue39769
--
nosy: +gregory.p.smith
___
Python
Gregory P. Smith added the comment:
https://bugs.python.org/issue39769 may be of interest. compileall's ddir= does
not behave properly in recursive subdirectories, it did the right thing in 2.7
which is similar to a combination of compile_dir(dir, prependdir=ddir,
stripdir=dir) after
Gregory P. Smith added the comment:
Ironically 3.9a4 gains some compileall enhancements that could be used as an
awkward workaround from https://bugs.python.org/issue38112:
python 2.7 compile_dir(d, ddir="") behavior can be had with
python 3.9a4 compile_dir(d, prependdir="&q
Gregory P. Smith added the comment:
This has probably been happening for many 3 releases. I noticed it on 3.6 when
investigating a problem with wrong paths in tracebacks coming from code which
we used compileall.compile_dir(src_root, quiet=1, ddir=") on.
I'm guessing ddir= (-d on th
New submission from Gregory P. Smith :
Easiest to demonstrate as such:
```shell
#!/bin/bash
mkdir bug
touch bug/__init__.py
mkdir bug/foo
touch bug/foo/__init__.py
touch bug/foo/bar.py
python3 -m compileall -d "" bug
python2 -m compileall -d "" bug
echo "prefix
Gregory P. Smith added the comment:
Reopening so that spending time on deciding this in the future at least stays
on my radar.
Your workaround sounds like the reasonable, if understandably not pretty
approach for now.
--
resolution: wont fix -> remind
status: closed ->
Change by Gregory P. Smith :
--
keywords: +3.4regression, 3.5regression
___
Python tracker
<https://bugs.python.org/issue25960>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
yes, Popen's use of a lock since that change means that Popen.wait() cannot be
called in an asynchronous context where its own execution could be blocking the
execution of code that would unlock the lock.
at this point we should probably just document
Gregory P. Smith added the comment:
Noted, but making it a keyword only argument would break a lot of existing code
that has always just been passing three positional args. Needless pain.
--
stage: patch review -> resolved
status: open ->
Gregory P. Smith added the comment:
Christian added the SHA3 support so is probably best to comment on this. The
way our hashlib code is structured we always use the
https://github.com/python/cpython/tree/master/Modules/_sha3 implementation
rather than OpenSSL for these algorithms due
Change by Gregory P. Smith :
--
versions: +Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue29249>
___
___
Python-bugs-list mailin
Gregory P. Smith added the comment:
thanks everyone!
--
resolution: -> fixed
stage: patch review -> commit review
status: open -> closed
versions: +Python 3.9
___
Python tracker
<https://bugs.python.or
Gregory P. Smith added the comment:
backport automation appears unhappy at the moment. I'm keeping this open and
assigned to me to manually run cherry_picker on this for 3.8 and 3.7 (if still
open for non-security fixes).
--
assignee: -> gregory.p.smith
stage: patch rev
Gregory P. Smith added the comment:
New changeset d3ae95e1e945ed20297e1c38ba43a18b7a868ab6 by Gregory P. Smith
(Alex Rebert) in branch 'master':
bpo-35182: fix communicate() crash after child closes its pipes (GH-17020)
(GH-18117)
https://github.com/python/cpython/commit
Gregory P. Smith added the comment:
fwiw, no need to remove that message. We'll want to make the docs clear that
this does not apply to Windows. :)
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Gregory P. Smith :
For more context, see https://bugs.python.org/issue39375 which seeks to
document the existing caveats.
POSIX lacks any APIs to access the process global environment in a thread safe
manner. Given this, we could _consider_ preventing os.putenv
Gregory P. Smith added the comment:
https://bugs.python.org/issue39376 tracks possible interpreter behavior changes.
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Gregory P. Smith :
The underlying API calls made by os.putenv() and os.environ[name] = value
syntax are not thread safe on POSIX systems. POSIX _does not have_ any thread
safe way to access the process global environment.
In a pure Python program, the GIL prevents
Gregory P. Smith added the comment:
Thanks Daniel!
--
nosy: +gregory.p.smith
resolution: -> fixed
stage: -> commit review
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Gregory P. Smith :
--
nosy: +christian.heimes
___
Python tracker
<https://bugs.python.org/issue37218>
___
___
Python-bugs-list mailing list
Unsub
Change by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue28254>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gregory P. Smith :
--
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python
3.7
___
Python tracker
<https://bugs.python.org/issue13
Gregory P. Smith added the comment:
i believe new work will be done via the new issue. marking this closed. if
there is something not covered by issue38576 that remains, please open a new
issue for it. new discussion on this long issue is easy to get lost in.
--
resolution
Change by Gregory P. Smith :
--
priority: normal -> high
___
Python tracker
<https://bugs.python.org/issue38576>
___
___
Python-bugs-list mailing list
Un
Gregory P. Smith added the comment:
Strictly speaking not all of those _need_ to be touched given the old name is
always going to exist for backwards compatibility. But I agree that we should
update them as part of this regardless.
I'd go forward with a PR.
The only fallout I expect
Gregory P. Smith added the comment:
do we have any buildbots using -X showrefcount?
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue38
Gregory P. Smith added the comment:
sweet! =)
--
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue33387>
___
___
Python-bug
Gregory P. Smith added the comment:
+1 to re-exposing a way to do PEP-523.
PEP-523 added a public API, we unintentionally hid it behind the mask of
Py_BUILD_CORE_MODULE in 3.8. We shouldn't remove PEP-523's abilities without a
deprecation cycle. But given the use cases tend to be "
Change by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue38500>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
.cleandoc is _probably_ more of what people want than .dedent? I hadn't
bothered to even try to pick between the two yet.
--
___
Python tracker
<https://bugs.python.org/issue36
Gregory P. Smith added the comment:
Another option not using a new letter: A triple-backtick token.
def foo():
value = ```this is a
long multi line string i don't want indented.
```
A discuss thread was started so I reconnected it with this issue. See
https
Change by Gregory P. Smith :
--
keywords: +patch
pull_requests: +16569
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17058
___
Python tracker
<https://bugs.python.org/issu
New submission from Gregory P. Smith :
importlib is full of str.format calls, modernizing it to use f-strings is a
slight performance win and much more readable.
--
assignee: gregory.p.smith
messages: 356005
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title
New submission from Gregory P. Smith :
We started down this path in https://bugs.python.org/issue31961 but had to
revert part of that before 3.7 as the implementation was incomplete making it
inconsistent across platforms. https://github.com/python/cpython/pull/4329.
Specifically accepting
New submission from Gregory P. Smith :
Creating an enum subclass (ie: defining an enum) is slow. This dramatically
impacts startup time of Python programs that import a bunch of potentially
needed constant definitions at startup before any proper code executes.
How slow? So slow
Change by Gregory P. Smith :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue38576>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Gregory P. Smith :
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue38576>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith added the comment:
I'm marking this fixed, technically it still exists in 2.7. it'll be up to
someone who cares about making a change to 2.7 to make a PR to go in there for
the final release. It has existed so long, I doubt it matters there.
--
resolution
Gregory P. Smith added the comment:
(read that as: feel free to keep the behavior for co_filename and path[0] and
lets see what happens :)
--
___
Python tracker
<https://bugs.python.org/issue20
Gregory P. Smith added the comment:
I think sys.argv[0] is the important one as program logic often tends to use
that as an input.
I'm honestly unsure of if this will be as much of a problem for .co_filename or
sys.path[0].
--
___
Python tracker
Gregory P. Smith added the comment:
There isn't really much we can do without a reasonable repeatable way to
reproduce the problem.
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue38
Change by Gregory P. Smith :
--
title: Make lib2to3 grammar more closely match Python -> Make lib2to3 grammar
better match Python, support the := walrus
___
Python tracker
<https://bugs.python.org/issu
Change by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue36541>
___
___
Python-
Change by Gregory P. Smith :
--
versions: +Python 2.7
___
Python tracker
<https://bugs.python.org/issue33348>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gregory P. Smith :
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue33348>
___
___
Python-
Change by Gregory P. Smith :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> lib2to3 doesn't parse f(*[] or [])
versions: +Python 3.8, Python 3.9 -Python 3.6
___
Python tracker
<https://
Change by Gregory P. Smith :
--
versions: +Python 3.9 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue33348>
___
___
Python-bugs-list mailin
701 - 800 of 3243 matches
Mail list logo
