[issue39075] types.SimpleNamespace should preserve attribute ordering (?)

[hai shi]

hai shi  added the comment:

IMHO, dropping the sort should be a default behavior. If some user need  
this feature, maybe we could supply a param to open the sort function or not?

--
nosy: +shihai1991

___
Python tracker 

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

[issue39071] email.parser.BytesParser - parse and parsebytes work not equivalent

[Abhilash Raj]

Change by Abhilash Raj :


--
nosy: +maxking

___
Python tracker 

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

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +inada.naoki

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

If there is a large chunk (e.g. several MBs), dropping the GIL during the 
memcpy of that chunk may be beneficial.  This kind of optimization may be 
applicable in other similar cases (such as extending a bytearray or a BytesIO 
object).

--
nosy: +pitrou

___
Python tracker 

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

[issue36051] Drop the GIL during large bytes.join operations?

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Could you show evidences that dropping the GIL can help you? bytes.join() needs 
to perform operations which needs to hold the GIL (allocating the memory, 
iterating the list, getting the data of bytes-like objects). I afraid that the 
cost of memcpy() is a minor part of this.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue36476] Runtime finalization assumes all other threads have exited.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> 1. Python daemon threads

I think the answer is to document a bit more clearly that they can pose all 
kinds of problems.  Perhaps we could even display a visible warning when people 
create daemon threads.

> 2. Python threads created in atexit handlers

We could run the "join non-daemon threads" routine a *second time* after atexit 
handlers have been called.  It probably can't hurt (unless people do silly 
things?).

> 3. non-Python threads accessing the C-API

This one I don't know how to handle. By construction, a non-Python thread can 
do anything it wants, and we cannot add guards against this at the beginning of 
each C API function. I think that when someone calls the C API, we're clearly 
in the realm of "consenting adults".

--

___
Python tracker 

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

[issue39117] Performance regression for making bound methods

[Raymond Hettinger]

New submission from Raymond Hettinger :

$ python3.9 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
100 loops, best of 11: 230 nsec per loop

$ python3.8 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
200 loops, best of 11: 149 nsec per loop

$ python3.7 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
200 loops, best of 11: 159 nsec per loop

$ python3.6 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a 
= A()' 'a.m; a.m; a.m; a.m; a.m'
1000 loops, best of 11: 0.159 usec per loop

Timings made using the recent released python.org macOS 64-bit builds.

--
components: Interpreter Core
messages: 358781
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Performance regression for making bound methods
type: performance
versions: Python 3.9

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue36788] Add clamp() function to builtins

[Batuhan]

Batuhan  added the comment:

Should this issue stay? Maybe port this discussion over python-ideas and after 
the resolution open it again?

--
nosy: +BTaskaya

___
Python tracker 

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

[issue29732] Heap out of bounds read in tok_nextc()

[Batuhan]

Batuhan  added the comment:

(.venv) [ 10:04ÖS ]  [ isidentical@x200:~/Downloads ]
 $ python -V
Python 3.9.0a1+
(.venv) [ 10:04ÖS ]  [ isidentical@x200:~/Downloads ]
 $ python python_hoobr_tok_nextc.py
  File "/home/isidentical/Downloads/python_hoobr_tok_nextc.py", line 5

^
SyntaxError: EOF while scanning triple-quoted string literal

--
nosy: +BTaskaya

___
Python tracker 

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

[issue39087] [C API] No efficient C API to get UTF-8 string from unicode object.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I like this idea, but I think that we should at least notify Python-Dev about 
all additions to the public C API. If somebody have objections or better idea, 
it is better to know earlier.

--

___
Python tracker 

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

[issue34444] Module's __file__ should be absolute always ("." in sys.path)

[Batuhan]

Batuhan  added the comment:

I am not sure about computing absolute path every time when `__file__` called. 
I guess it is a static thing, that get setted on the import time and never 
changes. What you are proposing is to compute it dynamically which IMHO isn't 
the best way.

--
nosy: +BTaskaya, brett.cannon, eric.snow, ncoghlan

___
Python tracker 

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

[issue32599] Add dtrace hook for PyCFunction_Call

[Batuhan]

Batuhan  added the comment:

If there are no objections, I can work on a patch.

--
nosy: +BTaskaya, christian.heimes, vstinner

___
Python tracker 

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

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It cannot be suppressed by the code in the module caused a warning, because the 
warning is emitted at compile time. You need to silence it before compiling 
that module. Once you have compiled it, warning will no longer be emitted.

--

___
Python tracker 

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

[issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate Pair

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue33772] Fix few dead code paths

[Benjamin Peterson]

Change by Benjamin Peterson :


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

___
Python tracker 

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

[issue39116] StreamReader.readexactly() raises GeneratorExit on ProactorEventLoop

[twisteroid ambassador]

New submission from twisteroid ambassador :

I have been getting these strange exception since Python 3.8 on my Windows 10 
machine. The external symptoms are many errors like "RuntimeError: aclose(): 
asynchronous generator is already running" and "Task was destroyed but it is 
pending!".

By adding try..except..logging around my code, I found that my StreamReaders 
would raise GeneratorExit on readexactly(). Digging deeper, it seems like the 
following line in StreamReader._wait_for_data():

await self._waiter

would raise a GeneratorExit.

There are only two other methods on StreamReader that actually does anything to 
_waiter, set_exception() and _wakeup_waiter(), but neither of these methods 
were called before GeneratorExit is raised. In fact, both these methods sets 
self._waiter to None, so normally after _wait_for_data() does "await 
self._waiter", self._waiter is None. However, after GeneratorExit is raised, I 
can see that self._waiter is not None. So it seems the GeneratorExit came from 
nowhere.

I have not been able to reproduce this behavior in other code. This is with 
Python 3.8.1 on latest Windows 10 1909, using ProactorEventLoop. I don't 
remember seeing this ever on Python 3.7.

--
components: asyncio
messages: 358774
nosy: asvetlov, twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: StreamReader.readexactly() raises GeneratorExit on ProactorEventLoop
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Zachary Ware]

Change by Zachary Ware :


--
keywords: +3.9regression

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Looking at changes to alpha2 I think it bisects to 
https://github.com/python/cpython/pull/6641


➜  cpython git:(5dcc06f6e0) git checkout 
fee552669f21ca294f57fe0df826945edc779090 && make -s -j4 > /dev/null 
Previous HEAD position was 5dcc06f6e0... bpo-38858: Allocate small integers on 
the heap (GH-17301)
HEAD is now at fee552669f... Produce cleaner bytecode for 'with' and 'async 
with' by generating separate code for normal and exceptional paths. (#6641)
➜  cpython git:(fee552669f) ./python ../backups/bpo39114.py 

3.9.0a1+ (tags/v3.9.0a1-43-gfee552669f:fee552669f, Dec 21 2019, 20:18:54) 
[GCC 4.8.4]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)
➜  cpython git:(fee552669f) git checkout 
fee552669f21ca294f57fe0df826945edc779090~1 && make -s -j4 > /dev/null
Previous HEAD position was fee552669f... Produce cleaner bytecode for 'with' 
and 'async with' by generating separate code for normal and exceptional paths. 
(#6641)
HEAD is now at 5dcc06f6e0... bpo-38858: Allocate small integers on the heap 
(GH-17301)
➜  cpython git:(5dcc06f6e0) ./python ../backups/bpo39114.py 
  
3.9.0a1+ (tags/v3.9.0a1-42-g5dcc06f6e0:5dcc06f6e0, Dec 21 2019, 20:21:07) 
[GCC 4.8.4]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

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

[issue39115] Clarify Python MIME type

[Josh de Kock]

New submission from Josh de Kock :

I'd like to add Python's MIME types to a database so that they can be properly 
used by other services. However, apart from the source code[1][2], I can't find 
any documentation from Python which highlights this. Is the source code correct 
here, and can it be taken as the 'official' MIME types from the project?

text/x-python py
application/x-python-code pyc pyo

[1]: 
https://github.com/python/cpython/blob/19a3d873005e5730eeabdc394c961e93f2ec02f0/Lib/mimetypes.py#L457
[2]: 
https://github.com/python/cpython/blob/19a3d873005e5730eeabdc394c961e93f2ec02f0/Lib/mimetypes.py#L528

--
assignee: docs@python
components: Documentation
messages: 358772
nosy: docs@python, jdek
priority: normal
severity: normal
status: open
title: Clarify Python MIME type
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue39114] Python 3.9.0a2 changed how finally/return is traced

[Ned Batchelder]

New submission from Ned Batchelder :

The way trace function reports return-finally has changed in Python 3.9.0a2. I 
don't know if this change is intentional or not.

(BTW: I want to put a 3.9regression keyword on this, but it doesn't exist.)

Consider this code:

--- 8< 
import linecache, sys

def trace(frame, event, arg):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, 
lineno).rstrip()))
return trace

print(sys.version)
sys.settrace(trace)

a = []
def finally_return():
try:
return 14
finally:
a.append(16)
assert finally_return() == 14
assert a == [16]
--- 8< 


(My habit is to use line numbers in the lines themselves to help keep things 
straight.)

In Python 3.7 (and before), the last traces are line 14, line 16, return 16.

In Python 3.8, the last traces are line 14, line 16, line 14, return 14.

In Python 3.9a1, the traces are the same as 3.8.

In Python 3.9a2, the traces are now line 14, line 16, line 14, line 16, return 
16.

This doesn't make sense to me: why does it bounce back and forth?

Full output from different versions of Python:

% /usr/local/pythonz/pythons/CPython-3.7.1/bin/python3.7 bpo.py
3.7.1 (default, Oct 20 2018, 18:25:32)
[Clang 10.0.0 (clang-1000.11.45.2)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)
% /usr/local/pythonz/pythons/CPython-3.8.1/bin/python3.8 bpo.py
3.8.1 (default, Dec 19 2019, 08:38:38)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a1/bin/python3.9 bpo.py
3.9.0a1 (default, Nov 20 2019, 18:52:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
retu 14: return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a2/bin/python3.9 bpo.py
3.9.0a2 (default, Dec 19 2019, 08:42:29)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13: try:
line 14: return 14
line 16: a.append(16)
line 14: return 14
line 16: a.append(16)
retu 16: a.append(16)

--
messages: 358771
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.9.0a2 changed how finally/return is traced
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue39052] import error when in python -m pdb debug mode

[Xavier de Gaye]

Xavier de Gaye  added the comment:

As a workaround insert the following hard-coded breakpoint before the import 
statement and run your script with python, i.e. 'python myhome.py' instead of 
'python -m pdb myhome.p'.

from pdb import Pdb; Pdb(skip=['importlib*']).set_trace()

--
nosy: +xdegaye

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[Tarn Yeong Ching]

Tarn Yeong Ching  added the comment:

GOD... I see. Thank you very much!

--

___
Python tracker 

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

[issue39110] UserList-subclass Tree slicing changes the original list unexpectedly

[Mark Dickinson]

Mark Dickinson  added the comment:

[ctarn]

> it works as expected with Python 3.6 (the owner of each of them is d), and 
> Python 3.8 and Python 3.7 work differently

The change in behaviour is the result of a bug fix that was applied in 3.7 and 
upwards: see GH-13169 and #27639.

As Eric says, UserList is behaving as intended here. Your problem stems from a 
design flaw in your code, namely that Nodes have owners. If a node exists both 
in a Tree *and* in a slice of that Tree (which slice, since the #27639 fix, is 
again a Tree), that node can't have both the original Tree *and* the slice as 
owner. In this case, what's happening is that accessing `d[0:1]` creates a new 
Tree object, and the __init__ method for that Tree object then reassigns the 
"owner" of the node in that slice.

> I don’t know what is discussion list

See https://www.python.org/community/lists/, and particularly 
https://mail.python.org/mailman/listinfo/python-list

Closing again here, but feel free to start a discussion or ask questions on the 
list above.

--
nosy: +mark.dickinson
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue33961] Inconsistency in exceptions for dataclasses.dataclass documentation

[Fabio Sangiovanni]

Change by Fabio Sangiovanni :


--
pull_requests: +17137
pull_request: https://github.com/python/cpython/pull/17677

___
Python tracker 

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

[issue36000] __debug__ is a keyword but not a keyword

[Batuhan]

Batuhan  added the comment:

import builtins
builtins.__dict__['__debug__'] = 'Surprise!'
builtins.__dict__['None'] = 'Surprise!'

print(__debug__)
print(None)

 $ ./python ../t.py
True
None

I guess this is related to Python/ast_opt.c transformation

case Name_kind:
if (_PyUnicode_EqualToASCIIString(node_->v.Name.id, "__debug__")) {
return make_const(node_, PyBool_FromLong(!optimize_), ctx_);
}
break;

--

___
Python tracker 

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

[issue30905] Embedding should have public API for interactive mode

[Batuhan]

Batuhan  added the comment:

> (1) BUT: The value of 'a' is not printed

Isn't this the expected behavior for file input? You need to call print() in 
order to get 'a' printed.

> (2) This is OK! We run one statement at a time

As it should be for "single input". 

> (3) This is NOT OK! Python throws a SyntaxError because we used 
> Py_single_input.

Yes, because AFAIK single stands for single statement. There are 2 (assign + 
expression)

> These two requirements are in conflict, because while Py_single_input enables 
> the first, it forbids the second.

It is why there is a code module which allows implementation of REPL loops.

--
nosy: +BTaskaya

___
Python tracker 

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