New submission from Ammar Askar :
Similar to https://bugs.python.org/issue46503 found by the ast.literal_eval
fuzzer
```
>>> f'{<'
python: Parser/string_parser.c:346: fstring_compile_expr: Assertion `*expr_end
== '}' || *expr_end == '!' || *expr_end == ':' || *expr_end == '='
Ammar Askar added the comment:
Hi Jeffrey, your second solution where you omit `-pie` is almost there. Instead
of modifying the Makefile you can pass `-pie` in `LINKFORSHARED`:
export CFLAGS="-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2"
export CXXFLAGS="-fPIC -fstac
Ammar Askar added the comment:
Looks like this got fixed somewhere along between 3.5 and 3.6
---
3.5
---
./python: can't open file 'id:000109': [Errno 2] No such file or directory
=
==28078==ERROR: LeakSanitizer: detected
Ammar Askar added the comment:
Looks like the latest versions of icc support this flag:
https://www.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/compiler-diagnostic-options/wunused
New submission from Ammar Askar :
Another parser crash found by the fuzzer:
"\
"(1for c in I,\
\
Recreator:
>>> import ast
>>> ast.literal_eval('"\\\n"(1for c in I,\\\n\\')
[1]17916 segmentation fault ./python
>>> import ast
>
New submission from Ammar Askar :
>From the newly added ast.literal_eval(x) fuzzer, the following string fed to
>ast.literal_eval will cause a null pointer in get_error_line:
\
(\
\
This can be recreated with:
❯ ./python
Python 3.11.0a1+ (heads/fuzz_ast-dirty:6c942a86a4,
Change by Ammar Askar :
--
components: +Library (Lib)
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
versions: +Python 3.11
___
Python tracker
<https://bugs.python
Change by Ammar Askar :
--
pull_requests: +27111
pull_request: https://github.com/python/cpython/pull/28777
___
Python tracker
<https://bugs.python.org/issue29
Change by Ammar Askar :
--
keywords: +patch
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +27109
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28774
___
Python tracker
<https://bugs.python.org/i
Ammar Askar added the comment:
Could you explain your use-case for this feature in a bit more detail? zipfile
is meant to be a relatively high level library to do common tasks such as
reading/writing/listing files.
The use case for `data_offset` proposed here seems to be relatively advanced
Change by Ammar Askar :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.11 -Python 3.5, Python 3.6, Python 3.7, Python
3.8
___
Python tracker
<https://bugs.python.or
Ammar Askar added the comment:
New changeset 0af681b652c43f0ba90988400ecc1e7934fbfc5d by Miss Islington (bot)
in branch '3.10':
[3.10] bpo-34990: Treat the pyc header's mtime in compileall as an unsigned int
(GH-19708)
https://github.com/python/cpython/commit
Ammar Askar added the comment:
New changeset 9d3b6b2472f7c7ef841e652825de652bc8af85d7 by Miss Islington (bot)
in branch '3.9':
[3.9] bpo-34990: Treat the pyc header's mtime in compileall as an unsigned int
(GH-19708)
https://github.com/python/cpython/commit
Ammar Askar added the comment:
Thank you for spotting this and the patch da-woods!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
versions: +Python 3.9
___
Python tracker
<https://
Ammar Askar added the comment:
New changeset ac811f9b5a68ce8756911ef2c8be83b46696018f by da-woods in branch
'main':
bpo-41886: Fix documented type of PyType_Type (GH-22454)
https://github.com/python/cpython/commit/ac811f9b5a68ce8756911ef2c8be83b46696018f
--
nosy: +ammar2
Change by Ammar Askar :
--
versions: +Python 3.11 -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue41
Change by Ammar Askar :
--
pull_requests: +25923
pull_request: https://github.com/python/cpython/pull/27390
___
Python tracker
<https://bugs.python.org/issue34
Ammar Askar added the comment:
Indeed, and the unicode_width package seems to implement the wcwidth algorithm:
* https://github.com/unicode-rs/unicode-width/blob/master/src/tables.rs#L39-L48
* https://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
https://bugs.python.org/issue12568 is an issue from
Ammar Askar added the comment:
I think this is the previous issue you are talking about Terry.
https://bugs.python.org/issue24665
The correct algorithm is a little more complex than just using
east_asian_widths. Ideally we would like to use the wcwidth function
(https://man7.org/linux/man
Ammar Askar added the comment:
Had some time to look into this. Just to summarize this problem, it deals with
unicode points that are single characters but take up more than the width of a
single character, even with a monospace font [1].
In the examples from above, the Chinese character
Ammar Askar added the comment:
Aah, I won't have time to investigate until Monday. I'll take a look then
unless someone gets to it first :)
--
___
Python tracker
<https://bugs.python.org/issue43
Ammar Askar added the comment:
As reported by Will McGugan on twitter:
Printing may be wrong for some unicode characters like:
Traceback (most recent call last):
File "test.py", line 1, in
x = ("该" / 0) + (1 / 2)
~~^
TypeError: unsupported operand
Change by Ammar Askar :
--
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue44624>
___
___
Python-bug
Ammar Askar added the comment:
Thanks for trying to help Leonardo! You might consider looking for easy issues
on the bug tracker or reviewing open pull requests to help. Definitely take a
look at the dev guide :) https://cpython-devguide.readthedocs.io/fixingissues/
--
resolution
Ammar Askar added the comment:
Brandt, maybe this regression test from a previous tracing bug might be useful
for the test writing:
https://github.com/python/cpython/pull/22026/files#diff-8b73bfc55514d8add8904c5f4d1d24b7b644ebfccba8d846085303577aa94dd6
--
nosy: +ammar2
Ammar Askar added the comment:
As per https://bugs.python.org/issue36249 and https://bugs.python.org/issue38351
We don't generally do large-scale changes that are mostly formatting based. We
would prefer that these sort of improvements happen when someone happens to be
touching that code
Change by Ammar Askar :
--
pull_requests: +25603
pull_request: https://github.com/python/cpython/pull/27047
___
Python tracker
<https://bugs.python.org/issue43
Change by Ammar Askar :
--
keywords: +patch
pull_requests: +25598
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27038
___
Python tracker
<https://bugs.python.org/issu
New submission from Ammar Askar :
During the implementation of PEP 657, Terry Jan Reedy pointed out that in the
format method of traceback.StackSummary there are two roles being fulfilled,
there is some logic to handle omitting repeated lines involved in recursive
calls and then the core per
Change by Ammar Askar :
--
pull_requests: +25582, 25583
pull_request: https://github.com/python/cpython/pull/27023
___
Python tracker
<https://bugs.python.org/issue43
Change by Ammar Askar :
--
pull_requests: +25582, 25583, 25584
pull_request: https://github.com/python/cpython/pull/27023
___
Python tracker
<https://bugs.python.org/issue43
Change by Ammar Askar :
--
pull_requests: +25582
pull_request: https://github.com/python/cpython/pull/27023
___
Python tracker
<https://bugs.python.org/issue43
Change by Ammar Askar :
--
nosy: +ammar2
nosy_count: 8.0 -> 9.0
pull_requests: +25524
pull_request: https://github.com/python/cpython/pull/26958
___
Python tracker
<https://bugs.python.org/issu
Change by Ammar Askar :
--
title: Edge case in when error displaying with non-utf8 lines -> Edge case in
compiler when error displaying with non-utf8 lines
___
Python tracker
<https://bugs.python.org/issu
New submission from Ammar Askar :
The AST currently stores column offsets for characters as byte-offsets.
However, when displaying errors, these byte-offsets must be turned into
character-offsets so that the characters line up properly with the characters
on the line when printed
Ammar Askar added the comment:
Indeed, it's quite a tricky issue so I'm glad it was caught in the beta.
Thank you for the report Anthony. Thanks for tracing the root cause and the fix
Victor and thank you to everyone who helped debug
Ammar Askar added the comment:
Just to thicken the mystery a bit further, if you comment out
import inspect
in dataclasses.py, the error also goes away.
--
___
Python tracker
<https://bugs.python.org/issue44
Ammar Askar added the comment:
The bisect was bizarre to say the least...
It points to commit 11159d2c9d6616497ef4cc62953a5c3cc8454afb
bpo-43080: pprint for dataclass instances (GH-24389)
* Added pprint support for dataclass instances which don't have a custom
__repr__.
which doesn't touch
Ammar Askar added the comment:
The segfault seems to be occuring on typeobject.c:1456 during interpreter
finalization:
if (type->tp_flags & Py_TPFLAGS_HEAPTYPE && !(base->tp_flags &
Py_TPFLAGS_HEAPTYPE))
where `type` seems to have already been deallocated.
Ammar Askar added the comment:
Can recreate on the latest 3.10 checkout, taking a look.
--
nosy: +ammar2
___
Python tracker
<https://bugs.python.org/issue44
Ammar Askar added the comment:
Seconded, also seeing the same ASAN failure on the fuzzers with a blame for
this commit.
--
nosy: +ammar2
___
Python tracker
<https://bugs.python.org/issue40
Ammar Askar added the comment:
Also, would it make sense to do a clean build (with the html output folder
wiped) in the build-cron to avoid this happening in the future?
--
___
Python tracker
<https://bugs.python.org/issue44
Ammar Askar added the comment:
Added Julien to the nosy list, looks like we might be retaining old deleted
docs pages.
--
nosy: +ammar2, mdk
___
Python tracker
<https://bugs.python.org/issue44
Ammar Askar added the comment:
With issue43888 being fixed with the removal of the coverage build, this is now
obsolete. Thanks for pointing out the codecov breach, we will make sure to
follow this if we ever re-add codecov.
--
resolution: -> out of date
stage: -> resolved
Ammar Askar added the comment:
Coverage builds have been removed from the CI, closing this now.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ammar Askar added the comment:
See also https://github.com/python/cpython/pull/25679 where we're proposing
just removing the coverage build altogether.
--
nosy: +ammar2
___
Python tracker
<https://bugs.python.org/issue43
Change by Ammar Askar :
--
keywords: +patch
nosy: +ammar2
nosy_count: 4.0 -> 5.0
pull_requests: +24416
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25724
___
Python tracker
<https://bugs.python.org/i
Ammar Askar added the comment:
Just a little update to this, now that issue34398 is fixed it is possible to
make this more beginner friendly by making sure the right terms have glossary
entries.
As an example, here is a search for "argument" on the latest docs:
https://docs.pytho
Ammar Askar added the comment:
Note that the `more_itertools` package on pypi also has a partition method.
Shall we close this off given that a recipe is already present and this is
available as part of a popular 3rd-party library?
--
nosy: +ammar2
Change by Ammar Askar :
--
pull_requests: +24370
pull_request: https://github.com/python/cpython/pull/25679
___
Python tracker
<https://bugs.python.org/issue43
Ammar Askar added the comment:
For what it's worth I think Brett's suggestion of just removing the coverage
build entirely is good too since it seems like no one actually looks at the
results and they take up valuable CI time.
--
nosy: +ammar2
Change by Ammar Askar :
--
pull_requests: +24234
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25516
___
Python tracker
<https://bugs.python.org/issu
Ammar Askar added the comment:
Looks like this is the issue described in the comment here:
https://github.com/python/cpython/blob/master/Lib/test/test_enum.py#L3691-L3692
On the first run you have the correct
('CONVERT_STRING_TEST_NAME_A', 5)
but later it turns
Ammar Askar added the comment:
Opened https://github.com/python/cpython/pull/25469 for the first suggestion of
reversing the precedence table order since it seems like a good improvement. I
think the tight binding to weak order is more natural and aside from K, the
following other languages
Change by Ammar Askar :
--
keywords: +patch
nosy: +ammar2
nosy_count: 8.0 -> 9.0
pull_requests: +24194
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25469
___
Python tracker
<https://bugs.python.org/i
Ammar Askar added the comment:
Marked as a duplicate.
Kaleb, would you mind posting your comment on the original bug #28197?
--
nosy: +ammar2
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Add start and stop parameters to the range
Ammar Askar added the comment:
Aah thanks for pointing that out Terry, I didn't realize f-strings have
different semantics for SyntaxError. Would you mind making a separate issue for
that, I'll look into making the documentation for it clearer after I get a
chance to investigate
Change by Ammar Askar :
--
keywords: +patch
pull_requests: +23900
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25153
___
Python tracker
<https://bugs.python.org/issu
New submission from Ammar Askar :
As pointed out by Guido in https://bugs.python.org/issue43555, we switched to
making the column offsets for SyntaxError be 1-indexed consistently in
https://bugs.python.org/issue34683
The rationale is explained by Guido and expanded upon in follow up
Ammar Askar added the comment:
This has been fixed as part of
https://github.com/python/docsbuild-scripts/pull/99
Thank you to Julien, our Google results are much cleaner now :)
--
resolution: -> fixed
stage: -> resolved
status: open -&g
Ammar Askar added the comment:
All the modules prescribed in the original bug are now actively being fuzzed,
thank you to Devin for the original work on this and Gregory for reviewing all
these changes.
I'm closing this now, feel free to make a new bug and nosy me in if there are
any other
Change by Ammar Askar :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Ammar Askar :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ammar Askar added the comment:
Thank you Steve and Zachary for reviewing, this warning is in the docs now.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ammar Askar added the comment:
Thank you to Julien for reviewing, we ended up going with our own solution
instead of waiting on Sphinx and I think it looks good :)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Change by Ammar Askar :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ammar Askar added the comment:
Just a note and possible design inspiration, pytest has pretty assertions like
this to allowing you to write unit tests purely with the assert statement and
not unittest's special `assert...` methods:
https://docs.pytest.org/en/stable/example
Change by Ammar Askar :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue43601>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ammar Askar added the comment:
> We should definitely document the column offset being 1-based
Yes please, I remember working on that issue to make it consistently 1-based a
while ago and I remember that the tooling was relying on 1-based indexes for
column offsets.
--
n
Change by Ammar Askar :
--
pull_requests: +23661
pull_request: https://github.com/python/cpython/pull/24896
___
Python tracker
<https://bugs.python.org/issue43
Ammar Askar added the comment:
Sure thing, I'll work on the backport.
--
___
Python tracker
<https://bugs.python.org/issue43499>
___
___
Python-bugs-list mailin
Change by Ammar Askar :
--
pull_requests: +23658
pull_request: https://github.com/python/cpython/pull/20508
___
Python tracker
<https://bugs.python.org/issue43
Change by Ammar Askar :
--
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +23657
pull_request: https://github.com/python/cpython/pull/20628
___
Python tracker
<https://bugs.python.org/issu
Change by Ammar Askar :
--
nosy: +eryksun
___
Python tracker
<https://bugs.python.org/issue43403>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ammar Askar :
--
nosy: +ammar2
nosy_count: 3.0 -> 4.0
pull_requests: +23435
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24650
___
Python tracker
<https://bugs.python.org/i
Ammar Askar added the comment:
It's still one of the most common beginner mistakes, personally I think the
trade-off in complexity at least for the grammar level fix is worth it here.
--
nosy: +ammar2
___
Python tracker
<https://bugs.python.
Change by Ammar Askar :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ammar Askar added the comment:
It seems to me that your commands are just sequenced wrong, in Python you're
performing (examples in parens):
* base64 (ue==) -> decode to binary (0xB9)
* binary (0xB9) -> encode to base64 (uQ==)
whereas in your command line commands you're doing:
*
Ammar Askar added the comment:
Additional discussion on the same topic on discourse:
https://discuss.python.org/t/reduce-the-overhead-of-functools-lru-cache-for-functions-with-no-parameters/3956
--
nosy: +ammar2
___
Python tracker
<ht
Ammar Askar added the comment:
`tb_frame` is documented under
https://docs.python.org/3/reference/datamodel.html
> Special read-only attributes: tb_frame points to the execution frame of the
> current level
`tb_code` can similarly be documented here and the note about the audit even
Change by Ammar Askar :
--
nosy: +eryksun
title: Optimization opportunity on Windows -> Build libraries with "/OPT:REF"
linker optimization on Windows
___
Python tracker
<https://bugs.pytho
New submission from Ammar Askar :
It is possible to access all the frame objects in the interpret without
triggering any audit hooks through the use of exceptions. Namely, through the
traceback's tb_frame property. Ordinarily one would trigger the
"sys._current_frames" or &quo
Ammar Askar added the comment:
Thank you Filipe and Mariatta, the fix looks good to me. I think it needs a
backport to the 3.9 branch though.
--
___
Python tracker
<https://bugs.python.org/issue42
Ammar Askar added the comment:
Any commit that gets to pushed to the master, 3.9, 3.8 and 3.7 branches.
e.g all the commits here https://github.com/python/cpython/commits/master, they
end up failing the "Check for source changes" step and skipping even when
there's non-documentati
New submission from Ammar Askar :
It looks like on pushes to Github, we currently aren't running tests. (Though
this isn't too big of a concern since they get run on pull requests).
Here's an example of a recent run
https://github.com/python/cpython/runs/1609911031
```
fatal: ambiguous
Ammar Askar added the comment:
This seems to be part 2 of the problems Mark mentioned in issue42562. Namely in
this case the `co_lnotab` accessor uses PyLineTable_NextAddressRange which has
that assertion.
--
nosy: +ammar2
___
Python tracker
Ammar Askar added the comment:
Confirmed, the attribute under
https://docs.python.org/3.10/library/email.headerregistry.html#email.headerregistry.ContentDispositionHeader
is incorrect.
bazwal, would you like to propose a patch to fix this? The code is here:
https://github.com/python
Ammar Askar added the comment:
> For me, the most surprising part is Handlers[signum].tripped which is
> declared as volatile *and* an atomic variable.
I think it's just following this part of the C spec (Some background in
bpo-12060):
> or refers to any object with static storage
Ammar Askar added the comment:
> Some compilers complain about checking `day < 0`, because `day` is an
> unsigned type
Just my two cents, this isn't just "some compilers". Everything from gcc, msvc,
C# to the rust compiler complain about this sort of c
Ammar Askar added the comment:
Oh whoops, got sniped by Brandt while investigating :)
--
___
Python tracker
<https://bugs.python.org/issue42574>
___
___
Pytho
Ammar Askar added the comment:
>From a quick glance at
>https://github.com/python/cpython/pulls?page=2=base%3A3.8+-label%3Atype-documentation
It looks like travis on 3.8 last passed at
https://github.com/python/cpython/pull/23364 around 19 days ago
The culprit commit is likely
Ammar Askar added the comment:
This doesn't show up in piping so I think it might be a Linux terminal
limitation. This thread claims a 4096 limit in cooked terminals, would you mind
giving one of the work-arounds here a try and see if it that gets rid of it:
https://unix.stackexchange.com
Ammar Askar added the comment:
Hey Victor, should we try to land this in Python 3.10?
Given that no one has brought up any big concerns aside from LD_PRELOAD based
hacks and how clang has already had this as the default I think it's relatively
safe to make a default for with-optimizations
Ammar Askar added the comment:
Related:
https://bugs.python.org/issue39828
--
nosy: +ammar2, vstinner
___
Python tracker
<https://bugs.python.org/issue42
Ammar Askar added the comment:
It's available from the Github gist that Kevin posted. Here is a direct link
that you can curl/wget:
https://gist.github.com/Zeturic/7d0480a94352968c1fe92aa62e8adeaf/raw/6daebaabedaa903016810c2c04d0d1f0b1af1ed3/data.bin
--
nosy: +ammar2
Ammar Askar added the comment:
For reference, this comes from
https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Modules/getbuildinfo.c#L45-L46
and is set by the compiler `__DATE__` macro.
GCC documentation says:
> If the day of the month is less than
Change by Ammar Askar :
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> More descriptive error message than "too many values to unpack"
___
Python tracker
<https://b
Ammar Askar added the comment:
Out of curiosity, what is the motivation for this optimization?
Is there reason to believe that range.index is performed often enough that it's
worth the extra code and maintenance cost here?
--
nosy: +ammar2
Ammar Askar added the comment:
Whoops, forgot the numpy link:
https://github.com/numpy/numpy/blob/33e1dbee8d9e11a3e96efaae822ff6f3c44e3cef/numpy/core/src/multiarray/number.c#L729-L741
--
___
Python tracker
<https://bugs.python.org/issue41
Ammar Askar added the comment:
Also of note, there is actually no way to call `PyNumber_InPlacePower` from
pure python from what I can tell. Even libraries like numpy don't implement the
three-argument version of the nb_inplace_power slot
1 - 100 of 461 matches
Mail list logo
