[issue42175] long lines from interactive stdin are truncated

2020-10-27 Thread Ammar Askar


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/questions/131105/how-to-read-over-4k-input-without-new-lines-on-a-terminal

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue42175>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38980] Compile libpython with -fno-semantic-interposition

2020-10-20 Thread Ammar Askar


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.

--

___
Python tracker 
<https://bugs.python.org/issue38980>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42005] profile/cProfile CLI should catch BrokenPipeError

2020-10-11 Thread Ammar Askar


Ammar Askar  added the comment:

Related:

https://bugs.python.org/issue39828

--
nosy: +ammar2, vstinner

___
Python tracker 
<https://bugs.python.org/issue42005>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41972] bytes.find consistently hangs in a particular scenario

2020-10-08 Thread Ammar Askar


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

___
Python tracker 
<https://bugs.python.org/issue41972>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41952] sys.version has double space between month and date

2020-10-06 Thread Ammar Askar


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 10, it is padded with a space on the 
> left.

and MSVC documentation says:

> The first character of date dd is a space if the value is less than 10. This 
> macro is always defined.


So I think we can close this as working-as-intended.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41952>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40202] Misleading grammatically of ValueError Message?

2020-10-03 Thread Ammar Askar


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://bugs.python.org/issue40202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41902] Micro optimization for range.index if step is 1

2020-10-01 Thread Ammar Askar


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

___
Python tracker 
<https://bugs.python.org/issue41902>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41903] PyNumber_InPlacePower ignores o3 if o1 implements __ipow__

2020-10-01 Thread Ammar Askar


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/issue41903>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41903] PyNumber_InPlacePower ignores o3 if o1 implements __ipow__

2020-10-01 Thread Ammar Askar


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.

--

___
Python tracker 
<https://bugs.python.org/issue41903>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41903] PyNumber_InPlacePower ignores o3 if o1 implements __ipow__

2020-10-01 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +brett.cannon

___
Python tracker 
<https://bugs.python.org/issue41903>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41903] PyNumber_InPlacePower ignores o3 if o1 implements __ipow__

2020-10-01 Thread Ammar Askar


Ammar Askar  added the comment:

Huh, this is weird. I wonder why the data model provides the signature

  object.__ipow__(self, other[, modulo])

if the slot always seems to drop the third argument.

Adding Brett to the nosy who found another issue around the special casing of 
pow/** recently. See also issue38302

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41903>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41833] threading.Thread: use target name if the name parameter is omitted

2020-09-22 Thread Ammar Askar


Ammar Askar  added the comment:

Having the target in the thread name definitely seems like a good idea and 
would help ease debugging, not just for our tests but when printing thread 
objects in general. 

I would agree with the suggestion of placing the counter in there for when 
multiple threads get spawned with the same target or maybe even using names 
like:

  Thread-1 (doit)
  Thread-2
  Thread-3 (print)

might be better just for people who are familiar with them.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41833>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41790] C-API documentation ignores heap types and says type objects must never be deallocated

2020-09-15 Thread Ammar Askar


Change by Ammar Askar :


--
title: C-API documentation -> C-API documentation ignores heap types and says 
type objects must never be deallocated

___
Python tracker 
<https://bugs.python.org/issue41790>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41688] Document how **= does not fall back on **

2020-09-09 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 2.0 -> 3.0
pull_requests: +21241
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22172

___
Python tracker 
<https://bugs.python.org/issue41688>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41743] Remove Unnecessarily Gendered Language from the Documentation

2020-09-08 Thread Ammar Askar


Change by Ammar Askar :


--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41743>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41743] Remove Unnecessarily Gendered Language from the Documentation

2020-09-08 Thread Ammar Askar


Ammar Askar  added the comment:

The other issue aside, changing

"If the programmer wishes to move to the next iteration of an outer enclosing 
loop, or terminate multiple loops at once, he or she has a few less-than 
elegant options."

to

"If the programmer wishes to move to the next iteration of an outer enclosing 
loop, or terminate multiple loops at once, they have a few less-than elegant 
options."

seems pretty straight forward. But like Victor said, this discussion should be 
happening on an issue in the peps repo and not here.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41743>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40624] add support for != (not-equals) in ElementTree XPath

2020-09-08 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 3.0 -> 4.0
pull_requests: +21229
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22147

___
Python tracker 
<https://bugs.python.org/issue40624>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41685] make doctest on 3.10 (master branch) fails with setuptools 50.0.0

2020-09-01 Thread Ammar Askar


Ammar Askar  added the comment:

Victor's fix is now in the 50.0.2 release, should we bump the pinned version, 
remove its pinning or do nothing?

https://github.com/pypa/setuptools/commit/edcf84faaf17e87e6e38796dd24f66d9236bf87c

https://pypi.org/project/setuptools/#history

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41685>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41670] ceval traces code differently based with USE_COMPUTED_GOTOS

2020-08-30 Thread Ammar Askar


Ammar Askar  added the comment:

So I think this is a weird edge case with a set of opcode predictions (GET_ITER 
-> FOR_ITER -> POP_BLOCK) going outside of a line boundary.

The disassembly of the reproducer above is:

  4   0 SETUP_FINALLY   16 (to 18)

  5   2 LOAD_CONST   1 (())
  4 GET_ITER
>>6 FOR_ITER 4 (to 12)
  8 STORE_FAST   0 (i)
 10 JUMP_ABSOLUTE6

  6 >>   12 POP_BLOCK
 14 LOAD_CONST   2 (1)
 16 RETURN_VALUE

When computed gotos are disabled and there is a tracing function, instructions 
0, 2, 4, 14 and 16 hit the `fast_next_opcode` label and have a chance to be 
traced as line hits. Note that `maybe_call_line_trace` will only cause a line 
hit if the instruction that starts a line (POP_BLOCK in this case) is being 
executed.

When computed gotos are enabled, DISPATCH is a no-op and there is a special 
case for when tracing is enabled that causes every opcode to go through 
`fast_next_opcode`: 
https://github.com/python/cpython/blob/c3a651ad2544d7d1be389b63e9a4a58a92a31623/Python/ceval.c#L1054-L1059

When computed gotos are not enabled, there is no similar check for PREDICT (and 
might be too costly to add) causing this issue: 
https://github.com/python/cpython/blob/c3a651ad2544d7d1be389b63e9a4a58a92a31623/Python/ceval.c#L1131-L1141

--
title: Windows and Linux execute the same code differently -> ceval traces code 
differently based with USE_COMPUTED_GOTOS

___
Python tracker 
<https://bugs.python.org/issue41670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41670] ceval traces code differently with USE_COMPUTED_GOTOS

2020-08-30 Thread Ammar Askar


Change by Ammar Askar :


--
title: ceval traces code differently based with USE_COMPUTED_GOTOS -> ceval 
traces code differently with USE_COMPUTED_GOTOS

___
Python tracker 
<https://bugs.python.org/issue41670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41670] Windows and Linux execute the same code differently

2020-08-30 Thread Ammar Askar


Ammar Askar  added the comment:

minimal reproducer without coverage:


import sys

def f():
try:
for i in []: pass
return 1
except:
return 2

def tracer(frame, event, _):
if event == 'line':
print("executing line {}".format(frame.f_lineno))
return tracer

sys.settrace(tracer)
f()



With computed gotos this results in:

> executing line 4
> executing line 5
> executing line 6

but without:

> executing line 4
> executing line 5

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41650] .pyc file not running in cross python versions

2020-08-27 Thread Ammar Askar


Ammar Askar  added the comment:

.pyc files aren't meant to be portable, they contain raw bytecode and data 
specific to the version of Python they were compiled on. For example, search 
for "Changed in version 3.6" here and you'll see all the little changes to the 
bytecode format: https://docs.python.org/3/library/dis.html

You'll have to compile your python source code on 3.6 if you intend to run it 
on a 3.6 interpreter.

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41650>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41610] Any Raspberry Pi Zero Projects to try?

2020-08-21 Thread Ammar Askar


Ammar Askar  added the comment:

Hi Supriya, this website is for reporting specific bugs about the Python 
language itself, not for general discussion.

I'd suggest taking a look at https://www.python.org/community/ and 
https://www.reddit.com/r/learnpython/ to find people to chat with about Python 
projects.

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41610>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41545] gc API requiring matching number of gc.disable - gc.enable calls

2020-08-14 Thread Ammar Askar


Ammar Askar  added the comment:

> I'd expected the GC to be truly enabled only on the second call to 
> `enable()`, but apparently it's enabled on the first call :( Both 
> `gc.enable()` and `gc.disable()` just write `1`/`0` to `gcstate->enabled`, 
> respectively.

I don't think this API makes much sense. I would expect `enable()` to enable 
the GC regardless of how many disable calls have been made. This is also in 
line with other functions like `faulthandler.enable()` / 
`bdb.Breakpoint.enable()`

I think the proper solution if you want to do this would be to wrap the 
disabling/enabling and keep track of the number of calls yourself.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41545>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41531] Python 3.9 regression: Literal dict with > 65535 items are one item shorter

2020-08-12 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +Mark.Shannon

___
Python tracker 
<https://bugs.python.org/issue41531>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40932] subprocess docs should warn of shlex use on Windows

2020-07-20 Thread Ammar Askar


Ammar Askar  added the comment:

Hmm, it'd be hard to enumerate them all. The module does say, "...simple 
syntaxes resembling that of the Unix shell" but that's it.

Distinguishing at the OS level for shlex does seem a bit weird given the 
existence of WSL and non-compliant shells on Linux like xonsh. I think it'd be 
nice if we could be a bit more specific on whats supported, maybe it covers all 
POSIX compliant shells?

For the subprocess warning I think it's fine to talk about the OS since it 
looks like the shell used are hard-coded in:

* 
https://github.com/python/cpython/blob/5241e189e77972d3a07acbbb3f0c0cbc2aeeb681/Lib/subprocess.py#L1403-L1407
* 
https://github.com/python/cpython/blob/5241e189e77972d3a07acbbb3f0c0cbc2aeeb681/Lib/subprocess.py#L1680-L1686

--

___
Python tracker 
<https://bugs.python.org/issue40932>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41286] Built-in platform module does not offer to check for processor instructions

2020-07-16 Thread Ammar Askar

Ammar Askar  added the comment:

Thanks for your understanding Boštjan, closing this as requested.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41286>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40932] subprocess docs should warn of shlex use on Windows

2020-07-15 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 7.0 -> 8.0
pull_requests: +20643
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21502

___
Python tracker 
<https://bugs.python.org/issue40932>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41283] The parameter name for imghdr.what in the documentation is wrong

2020-07-15 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 2.0 -> 3.0
pull_requests: +20642
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21501

___
Python tracker 
<https://bugs.python.org/issue41283>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41286] Built-in platform module does not offer to check for processor instructions

2020-07-15 Thread Ammar Askar


Ammar Askar  added the comment:

Your best bet then is probably using a library built for this purpose like 
https://github.com/workhorsy/py-cpuinfo

Like Christian said, exposing this information in the standard library would be 
a fairly large maintenance burden for a feature that can't really be actioned 
upon from pure Python code.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41286>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41271] Add support for io_uring to cpython

2020-07-15 Thread Ammar Askar


Ammar Askar  added the comment:

See also: https://github.com/python-trio/trio/issues/932 which contains a link 
to a library with cffi bindings to io_uring

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41271>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41275] Clarify whether Futures can be awaited multiple times

2020-07-14 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +aeros

___
Python tracker 
<https://bugs.python.org/issue41275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41122] functools.singledispatchfunction has confusing error message if no positional arguments are passed in

2020-07-14 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +20615
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21471

___
Python tracker 
<https://bugs.python.org/issue41122>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41257] mimetypes.guess_extension('video/x-matroska') return wrong value

2020-07-12 Thread Ammar Askar


Ammar Askar  added the comment:

This looks the same as issue38656, feel free to re-open if its not.

--
nosy: +ammar2
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41257>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Some CIs silence potentially useful output from make

2020-06-23 Thread Ammar Askar


Ammar Askar  added the comment:

Opened up a quick pull request to fix it: 
https://github.com/python/cpython/pull/21089

--

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Some CIs silence potentially useful output from make

2020-06-23 Thread Ammar Askar


Ammar Askar  added the comment:

Thanks for finding this Mark, looks like this was accidentally introduced in 
the 3.8 backport for testing the changes: 
https://github.com/python/cpython/pull/18670

The master (6aa1f1ecf7142a4117eedb8c570f30da1598616c) and 3.7 
(3bf9de2fb954bd1131f4f41517d7d5c316fb95f8) commits look clean.

--

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Some CIs silence potentially useful output from make

2020-06-23 Thread Ammar Askar


Change by Ammar Askar :


--
pull_requests: +20255
pull_request: https://github.com/python/cpython/pull/21089

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41030] Provide toList() method on iterators/generators (`list()` is a flow killer in REPL)

2020-06-19 Thread Ammar Askar


Ammar Askar  added the comment:

Julien, in the REPL "_" represents the last evaluated expression. So you can do:

>>> iter(range(10))

>>> list(_)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

Do you feel like that covers what you're asking for?

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue41030>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

2020-06-02 Thread Ammar Askar


Ammar Askar  added the comment:

There's still the "unknown pragma" warnings left, I pinged p-ganssle about it 
in the zoneinfo commit but it should probably be guarded like the ones in the 
ssl module:

https://github.com/python/cpython/blob/a871f692b4a2e6c7d45579693e787edc0af1a02c/Modules/_ssl.c#L46

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40686>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39943] Meta: Clean up various issues in C internals

2020-05-29 Thread Ammar Askar


Change by Ammar Askar :


--
pull_requests: +19754
pull_request: https://github.com/python/cpython/pull/20508

___
Python tracker 
<https://bugs.python.org/issue39943>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39943] Meta: Clean up various issues in C internals

2020-05-29 Thread Ammar Askar


Ammar Askar  added the comment:

For sre.c, this is definitely a bug in MSVC, see:

* 
https://stackoverflow.com/questions/10403713/why-does-visual-c-warn-on-implicit-cast-from-const-void-to-void-in-c-but
* https://godbolt.org/z/BpMqA_


I'm trying to get rid of MSVC warnings to unblock 
https://github.com/python/cpython/pull/18532 so I'll make a pull request that 
adds explicit casts for this.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39943>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35808] Let's retire pgen

2020-05-25 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +ammar2
nosy_count: 7.0 -> 8.0
pull_requests: +19667
pull_request: https://github.com/python/cpython/pull/20405

___
Python tracker 
<https://bugs.python.org/issue35808>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40705] use-after-free in _zoneinfo.c's module_free function

2020-05-20 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +19557
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/20280

___
Python tracker 
<https://bugs.python.org/issue40705>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40705] use-after-free in _zoneinfo.c's module_free function

2020-05-20 Thread Ammar Askar


New submission from Ammar Askar :

This was caught on oss-fuzz's ASAN builder:

Step #4: ==7656==ERROR: AddressSanitizer: heap-use-after-free on address 
0x604001568ea0 at pc 0x7f603e4b974b bp 0x7ffe4f7e8f90 sp 0x7ffe4f7e8f88
Step #4: READ of size 8 at 0x604001568ea0 thread T0
Step #4: #0 0x7f603e4b974a in module_free 
/src/cpython3/Modules/_zoneinfo.c:2610:10
Step #4: #1 0x570311 in module_dealloc 
/src/cpython3/Objects/moduleobject.c:675:9
Step #4: #2 0x57b7fc in _Py_Dealloc /src/cpython3/Objects/object.c:2209:5
Step #4: #3 0x54ce60 in _Py_DECREF /src/cpython3/./Include/object.h:430:9
Step #4: #4 0x551cdc in _Py_XDECREF /src/cpython3/./Include/object.h:497:9
Step #4: #5 0x54e1b2 in insertdict /src/cpython3/Objects/dictobject.c:1129:5
Step #4: #6 0x54d2fe in PyDict_SetItem 
/src/cpython3/Objects/dictobject.c:1579:12
Step #4: #7 0x55b5dc in dict_ass_sub 
/src/cpython3/Objects/dictobject.c:2179:16
Step #4: #8 0x87520f in PyObject_SetItem 
/src/cpython3/Objects/abstract.c:210:16
Step #4: #9 0x6c1e89 in _PyImport_Cleanup 
/src/cpython3/Python/import.c:523:13
Step #4: #10 0x6fc40a in Py_FinalizeEx 
/src/cpython3/Python/pylifecycle.c:1422:5
Step #4: #11 0x4dd17a in Py_RunMain /src/cpython3/Modules/main.c:634:9
Step #4: #12 0x4ddbea in pymain_main /src/cpython3/Modules/main.c:662:12
Step #4: #13 0x4dde34 in Py_BytesMain /src/cpython3/Modules/main.c:686:12
Step #4: #14 0x4dd030 in main /src/cpython3/./Programs/python.c:15:12
Step #4: #15 0x7f60440bc82f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Step #4: #16 0x434ce8 in _start (/src/cpython3/python+0x434ce8)
Step #4: 
Step #4: 0x604001568ea0 is located 16 bytes inside of 48-byte region 
[0x604001568e90,0x604001568ec0)
Step #4: freed by thread T0 here:
Step #4: #0 0x4ad20d in free 
/src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
Step #4: #1 0x57c493 in _PyMem_RawFree 
/src/cpython3/Objects/obmalloc.c:127:5
Step #4: #2 0x57dbc2 in PyObject_Free /src/cpython3/Objects/obmalloc.c:709:5
Step #4: #3 0x75e81a in PyObject_GC_Del 
/src/cpython3/Modules/gcmodule.c:2325:5
Step #4: #4 0x5a12cd in object_dealloc 
/src/cpython3/Objects/typeobject.c:4008:5
Step #4: #5 0x59abbb in subtype_dealloc 
/src/cpython3/Objects/typeobject.c:1371:5
Step #4: #6 0x57b7fc in _Py_Dealloc /src/cpython3/Objects/object.c:2209:5
Step #4: #7 0x7f603e4b0700 in _Py_DECREF 
/src/cpython3/./Include/object.h:430:9
Step #4: #8 0x7f603e4b05dc in _Py_XDECREF 
/src/cpython3/./Include/object.h:497:9
Step #4: #9 0x7f603e4b96de in module_free 
/src/cpython3/Modules/_zoneinfo.c:2609:5
Step #4: #10 0x570311 in module_dealloc 
/src/cpython3/Objects/moduleobject.c:675:9
Step #4: #11 0x57b7fc in _Py_Dealloc /src/cpython3/Objects/object.c:2209:5
Step #4: #12 0x54ce60 in _Py_DECREF /src/cpython3/./Include/object.h:430:9
Step #4: #13 0x551cdc in _Py_XDECREF /src/cpython3/./Include/object.h:497:9
Step #4: #14 0x54e1b2 in insertdict 
/src/cpython3/Objects/dictobject.c:1129:5
Step #4: #15 0x54d2fe in PyDict_SetItem 
/src/cpython3/Objects/dictobject.c:1579:12
Step #4: #16 0x55b5dc in dict_ass_sub 
/src/cpython3/Objects/dictobject.c:2179:16
Step #4: #17 0x87520f in PyObject_SetItem 
/src/cpython3/Objects/abstract.c:210:16
Step #4: #18 0x6c1e89 in _PyImport_Cleanup 
/src/cpython3/Python/import.c:523:13
Step #4: #19 0x6fc40a in Py_FinalizeEx 
/src/cpython3/Python/pylifecycle.c:1422:5
Step #4: #20 0x4dd17a in Py_RunMain /src/cpython3/Modules/main.c:634:9
Step #4: #21 0x4ddbea in pymain_main /src/cpython3/Modules/main.c:662:12
Step #4: #22 0x4dde34 in Py_BytesMain /src/cpython3/Modules/main.c:686:12
Step #4: #23 0x4dd030 in main /src/cpython3/./Programs/python.c:15:12
Step #4: #24 0x7f60440bc82f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Step #4: 
Step #4: previously allocated by thread T0 here:
Step #4: #0 0x4ad48d in malloc 
/src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
Step #4: #1 0x57c37c in _PyMem_RawMalloc 
/src/cpython3/Objects/obmalloc.c:99:12
Step #4: #2 0x57da49 in PyObject_Malloc 
/src/cpython3/Objects/obmalloc.c:685:12
Step #4: #3 0x75e17c in _PyObject_GC_Alloc 
/src/cpython3/Modules/gcmodule.c:2233:26
Step #4: #4 0x75e0c5 in _PyObject_GC_Malloc 
/src/cpython3/Modules/gcmodule.c:2260:12
Step #4: #5 0x598619 in PyType_GenericAlloc 
/src/cpython3/Objects/typeobject.c:1086:15
Step #4: #6 0x5a1922 in object_new 
/src/cpython3/Objects/typeobject.c:4002:12
Step #4: #7 0x59d2c7 in type_call /src/cpython3/Objects/typeobject.c:1017:11
Step #4: #8 0x4fbb0b in _PyObject_MakeTpCall 
/src/cpython3/Objects/call.c:191:18
Step #4: #9 0x4feefa in _PyObject_VectorcallTstate 
/src/cpython3/./Include/cpython/abstract.h:116:16
Step #4: #10 0x4fb5e7 in _PyObject_CallNoArgTstate 
/src/cpython3/./Include/internal/pycore_call.h:33:12
Step #4

[issue40551] PRs should be rebased on top of master before running the build/tests

2020-05-13 Thread Ammar Askar

Ammar Askar  added the comment:

Just like Travis, Github actions also automatically rebases pull requests onto 
the latest master. As you can see from a recent workflow run, it uses the 
special ref: "refs/remote/pull/20047/merge" 
https://github.com/python/cpython/pull/20047/checks?check_run_id=665377507#step:2:898

What is this ref that Github provides?

https://git-scm.com/book/en/v2/GitHub-Maintaining-a-Project
> There’s also a refs/pull/#/merge ref on the GitHub side,
> which represents the commit that would result if you push
> the “merge” button on the site. This can allow you to test
> the merge before even hitting the button


Unless there's real world examples of ongoing problems with PRs being merged 
with outdated test runs, I don't think this is worth complicating our CIs for.

As Inada-san mentioned, the occasional slip through will eventually be caught 
by the buildbots and promptly reverted. Re-triggering the CI for very stale 
pull requests might be worth doing. I'm kinda opposed to an automated system 
because this creates an undue burden on our CI providers, Travis graciously 
provides us with extra time for our coverage builds to finish already. 
Re-running pull requests that might never be merged is a lot of added work for 
them. Maybe we can get one of the bots to tag old pull requests and then have 
some guidance in the core-dev guide to re-run the CIs manually when merging 
those PRs.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40551>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40543] Tamil locale is using outdated encoding

2020-05-13 Thread Ammar Askar


Ammar Askar  added the comment:

Hi Muthu, thanks for reporting this! Looks like this is related to issue20087 
whereby the X11 locale data for TA_IN is using TSCII but the glibc supported 
file has the UTF-8 alias.

Pending a resolution to that bug, I think your best course of action would be 
to try to get this corrected upstream in x11, the code is here:

https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/locale.alias.pre#L1078

and their issue tracker is here:

https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues


Assuming that it gets accepted upstream, it should be simple enough to 
regenerate the locale module to use it.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40543>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40446] pow(a, b, p) where b=int((p-1)/2) spits out gibbrish for big p

2020-04-29 Thread Ammar Askar


Ammar Askar  added the comment:

And just to add on, the reason this gives you the correct result in Python 2 is 
that `/` performs integer division whereas in Python 3 the `/` operator 
provides a float as a result.

See https://docs.python.org/3/howto/pyporting.html#division for more details.

--
nosy: +ammar2
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40446>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40441] Plural typo in Design and History FAQ

2020-04-29 Thread Ammar Askar


Change by Ammar Askar :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40441>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40358] pathlib's relative_to should behave like os.path.relpath

2020-04-29 Thread Ammar Askar


Ammar Askar  added the comment:

Thank you for your work on this Domenico. For reviewing the code, would you 
mind creating a Github pull request for it as described here 
https://devguide.python.org/pullrequest/

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40358>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

2020-04-29 Thread Ammar Askar


Ammar Askar  added the comment:

There's been some additional discussion on 
https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue35829>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40439] Error in an external reference

2020-04-29 Thread Ammar Askar


Ammar Askar  added the comment:

Thank you for the report Patrick! 

For reference this is on the lexical analysis page: 
https://docs.python.org/3/reference/lexical_analysis.html

> A non-normative HTML file listing all valid identifier characters for Unicode 
> 4.1 can be found at 
> https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html.


Looking at the page on 
https://web.archive.org/web/20200312045240/https://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html

it seems like it was just a giant table containing all the valid XID_START and 
XID_CONTINUE characters. We could just remove the link or point it to the 
section in the current unicode database we use 
https://www.unicode.org/Public/13.0.0/ucd/DerivedCoreProperties.txt
where it lists all the characters:

> # Derived Property: XID_Start

Would you like to make a pull request for this?

--
keywords: +newcomer friendly
nosy: +ammar2, loewis

___
Python tracker 
<https://bugs.python.org/issue40439>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40317] inspect.getsource() examines incorrect target

2020-04-28 Thread Ammar Askar


Ammar Askar  added the comment:

Did you mean to close this Karthik?

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40317>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40401] pythoncore.vcxproj fails to load due to duplicated "..\Include\pyhash.h"

2020-04-26 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +19047
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19725

___
Python tracker 
<https://bugs.python.org/issue40401>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40401] pythoncore.vcxproj fails to load due to duplicated "..\Include\pyhash.h"

2020-04-26 Thread Ammar Askar


New submission from Ammar Askar :

The pythoncore project currently fails to load in Visual Studio with:

cpython\PCbuild\pythoncore.vcxproj : error  : Cannot load project with 
duplicated project items: ..\Include\pyhash.h is included as 'ClInclude' and as 
'ClInclude' item types. 


Looks like 
https://github.com/python/cpython/commit/c5fc15685202cda73f7c3f5c6f299b0945f58508#diff-fc48a1700be0140b57a172ea101297de
 accidentally introduced a duplicate for "..\Include\pyhash.h"

--
components: Windows
messages: 367334
nosy: ammar2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pythoncore.vcxproj fails to load due to duplicated "..\Include\pyhash.h"
type: compile error
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40401>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40385] Tools/checkpyc.py has been broken since PEP 552

2020-04-24 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +19030
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19709

___
Python tracker 
<https://bugs.python.org/issue40385>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34990] year 2038 problem in compileall.py

2020-04-24 Thread Ammar Askar


Change by Ammar Askar :


--
pull_requests: +19029
pull_request: https://github.com/python/cpython/pull/19708

___
Python tracker 
<https://bugs.python.org/issue34990>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13645] import machinery vulnerable to timestamp collisions

2020-04-24 Thread Ammar Askar


Change by Ammar Askar :


--
pull_requests:  -19023

___
Python tracker 
<https://bugs.python.org/issue13645>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40385] Tools/checkpyc.py has been broken since PEP 552

2020-04-24 Thread Ammar Askar


New submission from Ammar Askar :

Looks like checkpyc.py has been broken since PEP 552 was implemented 
https://github.com/python/cpython/blob/0e80b561d442769631d66f1cc8813ac30f97378e/Tools/scripts/checkpyc.py#L44-L46

It fails to read the 4 bytes for the `flags` field nor does it handle hash 
based files. 

Considering it's been broken since 2017 and no one has complained, it might be 
safe to remove this particular script.

--
components: Demos and Tools
messages: 367250
nosy: ammar2
priority: normal
severity: normal
status: open
title: Tools/checkpyc.py has been broken since PEP 552
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue40385>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13645] import machinery vulnerable to timestamp collisions

2020-04-24 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +ammar2
nosy_count: 8.0 -> 9.0
pull_requests: +19023
pull_request: https://github.com/python/cpython/pull/19651

___
Python tracker 
<https://bugs.python.org/issue13645>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue34990] year 2038 problem in compileall.py

2020-04-22 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +ammar2
nosy_count: 4.0 -> 5.0
pull_requests: +18977
pull_request: https://github.com/python/cpython/pull/19651

___
Python tracker 
<https://bugs.python.org/issue34990>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40277] Improve repr for _tuplegetter objects

2020-04-14 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 1.0 -> 2.0
pull_requests: +18885
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19537

___
Python tracker 
<https://bugs.python.org/issue40277>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40270] activate (or include) json1 extension in sqlite

2020-04-14 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
nosy: +ammar2
nosy_count: 5.0 -> 6.0
pull_requests: +18878
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/19528

___
Python tracker 
<https://bugs.python.org/issue40270>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40218] sys.executable is a false path if python is executed from gdb

2020-04-11 Thread Ammar Askar


Ammar Askar  added the comment:

The reason you're seeing gdb still work even when all Pythons are deleted is 
because it embeds a Python interpreter in itself 
(https://docs.python.org/3/extending/embedding.html).

This issue is thus out of scope here and belongs on the gdb tracker, but I can 
tell you it's caused by these lines: 
https://github.com/bminor/binutils-gdb/blob/de7ac122a7f98c181c1ec175b0560bb48eabc6ea/gdb/python/python.c#L1668-L1694

The Py_SetProgramName() is what informs the sys.executable value.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40218>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40202] Misleading grammatically of ValueError Message?

2020-04-09 Thread Ammar Askar


Ammar Askar  added the comment:

Jacob, let's skip the 2.7 part of the report since that is EOL now. For 
reference, the full error on the latest Python is:

>>> a, b, c, d = [1, 2, 3]
Traceback (most recent call last):
  File "", line 1, in 
ValueError: not enough values to unpack (expected 4, got 3)

>>> a, b = [1, 2, 3]
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2)


The first example already behaves as Steven describes, it gives the expected 
and actual count. In the second example it's difficult to calculate the x for 
"expected 2, got x" in general. This is because the iterable being unpacked 
could be a generator. For example, consider:

>>> a, b = itertools.repeat(42)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2)

However, we could improve the message if the object being unpacked does expose 
a length. I've attached a PR that does this, it makes the error look like:

>>> a, b = [1, 2, 3]
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack (expected 2, got 3)

Hopefully showing the amounts should help clarify why the error was thrown even 
if the wording seems a bit iffy.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40202] Misleading grammatically of ValueError Message?

2020-04-09 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +18801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19446

___
Python tracker 
<https://bugs.python.org/issue40202>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40176] unterminated string literal tokenization error messages could be better

2020-04-03 Thread Ammar Askar


Ammar Askar  added the comment:

Just re-posting this here from the open PR. Rust's handling of this seems nice 
and beginner friendly:

  error: unterminated double quote string
   --> src/main.rs:2:19
|
  2 |   let message = "Hello world
|  ___^
  3 | | println!(message);
  4 | | }
| |_^

Like Serhiy suggested, it points to the /start/ of the string, rather than the 
EOL and the message seems nice too.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40176>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40118] os.stat in linux shows the wrong inode

2020-04-03 Thread Ammar Askar


Ammar Askar  added the comment:

As noted in the documentation for os.stat 
(https://docs.python.org/3.9/library/os.html#os.stat):

> This function normally follows symlinks; to stat a symlink add the argument 
> follow_symlinks=False, or use lstat().

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40118>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39865] getattr silences an unrelated AttributeError

2020-04-02 Thread Ammar Askar


Ammar Askar  added the comment:

Update: opened up https://github.com/python/cpython/pull/19303 as a quick first 
pass at implementing this. It works as expected and retains the context from 
the original exception just in case it's needed. The code isn't too pretty, 
looks like exception chaining was primarily designed to be a first class 
citizen using the `raise e2 from e` syntax. A helper in exceptions.c would 
definitely go a long way to making it more readable.

--

___
Python tracker 
<https://bugs.python.org/issue39865>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39865] getattr silences an unrelated AttributeError

2020-04-02 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +18665
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19303

___
Python tracker 
<https://bugs.python.org/issue39865>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39865] getattr silences an unrelated AttributeError

2020-03-31 Thread Ammar Askar


Ammar Askar  added the comment:

As unfortunate as this is, I don't think there's an easy way to solve this 
while adhering to descriptors and the attribute lookup model. This is a 
consequence of the following rule:

> object.__getattr__(self, name):
>   Called when the default attribute access fails with an
>   AttributeError (either __getattribute__() raises an AttributeError
>   because name is not an instance attribute or an attribute in the
>   class tree for self; or __get__() of a name property raises
>   AttributeError)

As it notes, if the __get__() raises an AttributeError then a fallback to 
__getattr__ is initiated. One may think that maybe we can just catch 
AttributeError in @property to try to fix this problem but a quick search shows 
that people do intentionally raise AttributeError in @property methods:

* 
https://github.com/kdschlosser/EventGhost-TPLink/blob/a4a642fde8dd4deba66262a36d673cbbf71b8ceb/TPLink/tp_link/rule.py#L148-L152

* 
https://github.com/ajayau404/sniffer/blob/cd0c813b8b526a3c791735a41b13c7677eb4aa0e/lib/python3.5/site-packages/vpython/vpython.py#L1942-L1944

While this in combination with a __getattr__ is rare, I was able to find one 
example:

* 
https://github.com/xrg/behave_manners/blob/19a5feb0b67fe73cd902a959f0d038b905a69b38/behave_manners/context.py#L37

I don't think that changing this behavior is acceptable as people might be 
relying on it and it's well documented.


In your case, I think it's really the "catch-all" __getattr__ that's at fault 
here which really shouldn't be returning None for all attributes blindly. This 
does bring up a good point though that in the process of this fall-back 
behavior, the original AttributeError from A's property does get masked. What 
can be done and might be a good idea is to show the original AttributeError 
failure as the cause for the second. Something like this:

  Traceback (most recent call last):
File "", line 2, in 
File "", line 5, in myprop
  AttributeError: 'int' object has no attribute 'foo'

  The above exception was the direct cause of the following exception:

  Traceback (most recent call last):
File "", line 7, in 
File "", line 5, in 
File "", line 7, in __getattr__
  AttributeError: not found in __getattr__

This at least somewhat indicates that the original descriptor __get__ failed 
and then __getattr__ also raised. As opposed to now where the original 
exception gets masked:

  >>> class A:
  ...   @property
  ...   def myprop(self):
  ... a = 1
  ... a.foo
  ...   def __getattr__(self, attr_name):
  ... raise AttributeError("not found in __getattr__")
  ...
  >>> a = A()
  >>> a.myprop
  Traceback (most recent call last):
File "", line 1, in 
File "", line 7, in __getattr__
  AttributeError: not found in __getattr__

I'm gonna take a stab at implementing this real quick to see if it's actually 
useful and viable.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39865>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38237] Expose meaningful keyword arguments for pow()

2020-03-25 Thread Ammar Askar


Change by Ammar Askar :


--
pull_requests: +18531
pull_request: https://github.com/python/cpython/pull/19171

___
Python tracker 
<https://bugs.python.org/issue38237>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40012] Avoid Python 2 documentation to appear in Web search results

2020-03-25 Thread Ammar Askar


Ammar Askar  added the comment:

Instead of noindex maybe the 3.x documentation can be marked as the canonical 
one: https://support.google.com/webmasters/answer/139066

This should still allow the old docs to be crawled but emphasize the latest 
docs on the website:

> Google Search result usually points to the canonical page, unless one of the 
> duplicates is explicitly better suited for a user: for example, the search 
> result will probably point to the mobile page if the user is on a mobile 
> device, even if the desktop page is marked as canonical.

Presumably the "better suited" means that if you search for "python2 timeit" 
you'd still find the py2 docs.

Terry Reedy, could you link the earlier issue so this information can be posted 
there, or are you referring to the issue Karthik linked?

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue40012>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38237] Expose meaningful keyword arguments for pow()

2020-03-17 Thread Ammar Askar


Ammar Askar  added the comment:

I don't think that matters. The example is supposed to just serve as an 
illustration, it doesn't need to encode the dunder dispatch semantics. The 
already existing example doesn't check for a __pow__.

I'd picture it just as:

return x//y, x%y

--

___
Python tracker 
<https://bugs.python.org/issue38237>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38237] Expose meaningful keyword arguments for pow()

2020-03-17 Thread Ammar Askar


Ammar Askar  added the comment:

In my original PR I changed it to divmod: 
https://github.com/python/cpython/pull/16302/files#diff-986275b975a33c44c0aba973362516fa

--

___
Python tracker 
<https://bugs.python.org/issue38237>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue14126] Speed up list comprehensions by preallocating the list where possible

2020-03-07 Thread Ammar Askar


Ammar Askar  added the comment:

Aah, thanks for the catcher Victor. Missed that this was about list 
/comprehensions/, not the list constructor.

--

___
Python tracker 
<https://bugs.python.org/issue14126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue14126] Speed up list comprehensions by preallocating the list where possible

2020-03-06 Thread Ammar Askar


Ammar Askar  added the comment:

I believe this was implemented in issue33234

--
nosy: +ammar2
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Improve list() pre-sizing for inputs with known lengths

___
Python tracker 
<https://bugs.python.org/issue14126>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39689] test_struct failure on s390x Fedora Clang buildbot

2020-03-03 Thread Ammar Askar


Ammar Askar  added the comment:

Nothing too interesting, here's the stack trace:

/src/cpython3/Modules/_struct.c:487:28: runtime error: load of value 32, which 
is not a valid value for type '_Bool'
#0 0x7f50371a7670 in nu_bool cpython3/Modules/_struct.c:487:28
#1 0x7f503719ea3d in s_unpack_internal cpython3/Modules/_struct.c:1512:21
#2 0x7f5037199f7e in unpack cpython3/Modules/clinic/_struct.c.h:259:20
#3 0xb8b8bc in cfunction_vectorcall_FASTCALL 
cpython3/Objects/methodobject.c:366:24
#4 0x4fe113 in _PyObject_VectorcallTstate 
cpython3/./Include/cpython/abstract.h:111:21
#5 0x4fe51f in object_vacall cpython3/Objects/call.c:789:14
#6 0x4fe7d8 in PyObject_CallFunctionObjArgs cpython3/Objects/call.c:896:14
#7 0x4d394e in fuzz_struct_unpack 
cpython3/Modules/_xxtestfuzz/fuzzer.c:121:26
#8 0x4d394e in _run_fuzz cpython3/Modules/_xxtestfuzz/fuzzer.c:398:14
#9 0x4d394e in LLVMFuzzerTestOneInput 
cpython3/Modules/_xxtestfuzz/fuzzer.c:453:11

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39689>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39704] Disable code coverage

2020-03-02 Thread Ammar Askar


Ammar Askar  added the comment:

Just a quick update, I think this is a codecov bug as per here: 
https://community.codecov.io/t/prs-are-commented-even-with-comment-off/941

The yaml configuration doesn't show up here: 
https://codecov.io/gh/python/cpython/settings/yaml

While we wait for a response from codecov, we can fix this in the interim by 
overriding the settings at an organization level. An owner of the Python 
organization can enable this here: the organization level stuff would be here: 
https://codecov.io/account/gh/python/yaml

placing

```
comment: off
coverage:
  status:
changes: off
project: off
patch: off
```

as the config should hopefully fix this for now.

--

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39821] grp library functions grp.getgrnam() & grp.getgrgid() returning incorrect gr_mem information

2020-03-01 Thread Ammar Askar


Ammar Askar  added the comment:

I can't re-create this locally (tested on master and 3.5.2):

  ammar@cowlick:~/cpython$ getent group | grep testgroup
  testgroup:x:1008:ammar,root
  ammar@cowlick:~/cpython$ ./python
  Python 3.9.0a4+ (heads/master:02a4d57, Feb 27 2020, 01:54:32)
  [GCC 5.4.0 20160609] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import grp
  >>> grp.getgrnam('testgroup')
  grp.struct_group(gr_name='testgroup', gr_passwd='x', gr_gid=1008, 
gr_mem=['ammar', 'root'])

Both getgrnam and getgrall use the same underlying function to convert the 
`struct group` so this might be a problem with your libc. Could you post your 
distro info?

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39821>
___
___
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, & struct modules to oss-fuzz testing

2020-02-27 Thread Ammar Askar


Change by Ammar Askar :


--
nosy: +ammar2
nosy_count: 9.0 -> 10.0
pull_requests: +18043
pull_request: https://github.com/python/cpython/pull/18679

___
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



[issue39704] Disable code coverage

2020-02-27 Thread Ammar Askar


Ammar Askar  added the comment:

Looks like it was just cached, the latest pull request didn't get a codecov 
comment nor was it ran on the latest commit: 
https://github.com/python/cpython/pull/18682

Should this be back-ported so backport pull requests/pull requests to other 
versioned branches don't get affected by this either?

--

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39704] Disable code coverage

2020-02-27 Thread Ammar Askar


Ammar Askar  added the comment:

Can someone with access check that 
https://codecov.io/gh/python/cpython/settings/yaml has the right config? The 
latest run after my PR was pushed through still has the status check running :(

--

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39704] Disable code coverage

2020-02-27 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +18039
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18680

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39777] Use the codecov GH Action

2020-02-27 Thread Ammar Askar


Ammar Askar  added the comment:

On a second look, we currently do this anyway: 
https://github.com/python/cpython/blob/374d998b507d34a6c0a3816a163926a8ba0c483f/.github/workflows/coverage.yml#L66-L70

and don't run coverage for PRs so it shouldn't matter.

--

___
Python tracker 
<https://bugs.python.org/issue39777>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39777] Use the codecov GH Action

2020-02-27 Thread Ammar Askar


Ammar Askar  added the comment:

This has the disadvantage that it won't work for PRs because Github doesn't 
make secrets like `${{ secrets.CODECOV_TOKEN }}` available in PRs.

See: https://github.com/codecov/codecov-action/issues/29

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39777>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39704] Disable code coverage

2020-02-27 Thread Ammar Askar


Ammar Askar  added the comment:

Thanks for the pointer Brett, I'll submit a PR.

--

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39729] stat.S_ISXXX can raise OverflowError for remote file modes

2020-02-23 Thread Ammar Askar


Ammar Askar  added the comment:

Size of the mode aside, isn't this approach problematic anyway? One platform 
could have an entirely different way of signalling ISDIR vs another. In this 
case using the host's S_ISDIR for the remote's mode would result in possibly 
incorrect values.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39729>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39726] ctypes on pypi has fallen behind

2020-02-22 Thread Ammar Askar


Ammar Askar  added the comment:

The ctypes on pypi is no longer maintained as it was merged by the original 
author Thomas Heller into python itself. 

This article goes over the history of it a little: 
https://blog.python.org/2011/04/thomas-heller-steps-down-as-ctypes.html

Why do you need the pypi version to be updated? You should just be able to 
import ctypes in your venv and have it use the one included in the standard 
library.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39726>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39180] Missing getlines func documentation from linecache module

2020-02-22 Thread Ammar Askar


Ammar Askar  added the comment:

A good place to start is looking at the blame to find the commit that 
introduced it. Which was:

https://github.com/python/cpython/commit/17ab123cf1f0597e7e257c1ce83a6e87b85ffd7b#diff-71666751dc5821f7fc30e9c8138019c9

and if we browse to the state of the file before that commit we see:

https://github.com/python/cpython/blob/bbd89b66b1b3c44836f560b60c7a176a6172f148/Lib/linecache.py#L32-L39

which indicates that it used to be exposed but was maybe overlooked when 
__all__ was added.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39180>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39704] Disable code coverage

2020-02-21 Thread Ammar Askar


Ammar Askar  added the comment:

Also just to clarify, the actual coverage build which measures the build. That 
is:

https://github.com/python/cpython/blob/d4d17fd2cf69e7c8f4cd03fbf2d575370945b952/.travis.yml#L75-L114

is fine. The build succeeds and the coverage can be seen online at 
https://codecov.io/gh/python/cpython to get a high-level overview of coverage.

The integration with codecov as a status check and it's comments are the real 
nuisance.

--

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39704] Disable code coverage

2020-02-20 Thread Ammar Askar


Ammar Askar  added the comment:

Agreed, it's way too noisy. This PR which touches absolutely no code 
https://github.com/python/cpython/pull/18583#issuecomment-589432937

claims to "increase coverage by 1.01%."

This doesn't really add much value and only adds noise in the pull requests.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39704>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Some CIs silence potentially useful output from make

2020-02-20 Thread Ammar Askar


Change by Ammar Askar :


--
keywords: +patch
pull_requests: +17953
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18583

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Some CIs silence potentially useful output from make

2020-02-20 Thread Ammar Askar


Change by Ammar Askar :


--
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open
title: Ubuntu Github action not fully running build process -> Some CIs silence 
potentially useful output from make
type: behavior -> enhancement

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39695] Failed to build _uuid module, but libraries was installed

2020-02-20 Thread Ammar Askar


Ammar Askar  added the comment:

Sorry about your experience Marco but I think the dev guide is pretty clear on 
all these steps (including having to redo `make clean`). You can find some 
discussion on the build system here 
https://discuss.python.org/t/is-there-prior-discussion-around-the-build-system-of-cpython-itself/2813
 but for now I'm going to close this as "not-a-bug" because the dev guide 
covers it.

If your proposal is to make dependent modules build without re-configuring, 
please contribute to that discussion or bring it up on the ideas forum.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39695>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Ubuntu Github action not fully running build process

2020-02-20 Thread Ammar Askar


Ammar Askar  added the comment:

Aah sorry. This was my mistake, I didn't notice that we're passing `-s` 
(silent) to make. It is actually performing the build underneath, just not with 
the outputs that get produced form other CIs.

Steve, is there a reason the Github action and Azure pipelines:

* 
https://github.com/python/cpython/blob/1246d892038a693304549f8574e6c2784b91589a/.azure-pipelines/posix-steps.yml#L23

* 
https://github.com/python/cpython/blob/1246d892038a693304549f8574e6c2784b91589a/.github/workflows/build.yml#L58

both pass `-s` to make but Travis doesn't? It seems like it might potentially 
hide useful information about the build.

* 
https://github.com/python/cpython/blob/1246d892038a693304549f8574e6c2784b91589a/.travis.yml#L170

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39699] Ubuntu Github action not fully running build process

2020-02-20 Thread Ammar Askar


New submission from Ammar Askar :

I think the Github action for building CPython on Ubuntu is accidentally 
caching the built Python files.

If we take a look at: https://github.com/python/cpython/runs/455936632#step:7:1
and
https://github.com/python/cpython/pull/18567/checks?check_run_id=457662461#step:8:1

It seems like it's running way too fast (and producing too little output) to 
actually be building all of CPython.

Adding Steve who originally authored the action to the nosy list to see if they 
might have any insight.

--
components: Build
messages: 362316
nosy: ammar2, steve.dower
priority: normal
severity: normal
status: open
title: Ubuntu Github action not fully running build process
type: behavior

___
Python tracker 
<https://bugs.python.org/issue39699>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39696] Failed to build _ssl module, but libraries was installed

2020-02-20 Thread Ammar Askar


Ammar Askar  added the comment:

As pointed out in your other issue:

https://devguide.python.org/setup/#unix

> If you decide to Install dependencies, you will need to re-run both configure 
> and make.

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue39696>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39695] Failed to build _uuid module, but libraries was installed

2020-02-20 Thread Ammar Askar


Ammar Askar  added the comment:

Is this still a problem after you run configure again?

As pointed out in https://devguide.python.org/setup/#unix

> If you decide to Install dependencies, you will need to re-run both configure 
> and make.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39695>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39694] Incorrect dictionary unpacking when calling str.format

2020-02-20 Thread Ammar Askar


Ammar Askar  added the comment:

Can re-create, this is because the **kwargs handling inside unicode format only 
performs a lookup when needed 
https://github.com/python/cpython/blob/c4cacc8c5eab50db8da3140353596f38a01115ca/Objects/stringlib/unicode_format.h#L393-L424
 and doesn't eagerly check it like here 
https://github.com/python/cpython/blob/ffd9753a944916ced659b2c77aebe66a6c9fbab5/Objects/call.c#L985-L1010

This might not be worth fixing though because of the very common pattern of 

  "{abcd}".format(**locals())

This would take a pretty dramatic performance hit for a relatively uncommon 
edge case.

--
nosy: +ammar2, eric.smith, serhiy.storchaka, vstinner

___
Python tracker 
<https://bugs.python.org/issue39694>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39625] Traceback needs more details

2020-02-16 Thread Ammar Askar


Ammar Askar  added the comment:

I don't know how common this situation is, the fact that all constructors go to 
__init__ here makes it a little tough in this case but normally you'd be able 
to tell by the function name.

One potential solution might be to show which file the error came from like 
this:

Traceback (most recent call last):
  File "D:\x.py", line 13, in 
c = C(C1("C1"), C2("C2"))
TypeError: [D:\x.py:6] __init__() missing 1 required positional argument: 'p'

This is a pretty trivial change in ceval.c:3779 but might make the errors 
pretty long unless (especially now that co_filename is an absolute path) we 
chop them off to just the name of the file.

Including the frame information for the function about to be called would be 
much more difficult.

Overall this situation might not be worth improving because it's so rare but 
having the function location in the error might be worth having just as an 
extra information point.

--
nosy: +ammar2

___
Python tracker 
<https://bugs.python.org/issue39625>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   >