[issue32566] Not able to open Python IDLE

New submission from Kiran : Hello, I am new to Python and installed python3 recently and when I try to open IDLE, Iam getting the error attached. Please let me know how to resolve it. Thanks. -- components: Windows files: Python.jpg messages: 310062 nosy:

[issue32534] Speed-up list.insert

STINNER Victor added the comment: > jeethu@dev:cpython (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" > "for _ in range(100): l.insert(0, None)" Please don't use timeit, but perf timeit to run such *microbenchmark* (time smaller than 1 ms). Your

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

Raymond Hettinger added the comment: New changeset b44c5169f64178d2ff2914187b315549e7ab0cb6 by Raymond Hettinger in branch 'master': bpo-26163: Frozenset hash improvement (#5194) https://github.com/python/cpython/commit/b44c5169f64178d2ff2914187b315549e7ab0cb6

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

Change by Roundup Robot : -- pull_requests: +5052 ___ Python tracker ___

[issue32565] Document the version of adding opcodes

New submission from Serhiy Storchaka : The version of adding a new opcode is not specified for some opcodes. The proposed PR adds missed 'versionadded' directives (as usually, only when added after 3.0). -- assignee: docs@python components: Documentation

[issue32564] Syntax error on using variable async

Serhiy Storchaka added the comment: It raised a DeprecationWarning since 3.5. Most projects got rid of "async" and "await" identifiers before 3.7. File a bug in the Pika library. -- ___ Python tracker

[issue32534] Speed-up list.insert

Antoine Pitrou added the comment: Thanks. That's really surprising. I'll give it a try myself. -- ___ Python tracker ___

[issue11849] glibc allocator doesn't release all free()ed memory

Antoine Pitrou added the comment: Well, memory fragmentation can happen with any allocation scheme, and it's possible even Python 3 isn't immune to this. Backporting performance improvements is a strain on our resources and also constitutes a maintenance threat (what if the

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Moore added the comment: Agreed, the docs don't need to mention PATHEXT. I don't have a machine to hand with Python 3.6 not installed, to check, but I believe the launcher is installed by default (although as you say it can be deselected - and it's definitely

[issue32534] Speed-up list.insert

Jeethu Rao added the comment: Built and benchmarked both the baseline and the patch without PGO; the differences are less pronounced, but still present. https://gist.github.com/jeethu/abd404e39c6dfcbabb4c01661b9238d1 -- ___

[issue11849] glibc allocator doesn't release all free()ed memory

Bob Kline added the comment: Sorry, I should have used the language of the patch author ("the resolution"). Without the resolution, Python 2.7 eventually runs out of memory and crashes for some correctly written user code. --

[issue32564] Syntax error on using variable async

Change by Andrew Olefira : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue32564] Syntax error on using variable async

Andrew Olefira added the comment: Yes, I understand, but "not recommended" != "not allowed". For example library Pika (https://pypi.python.org/pypi/pika) use variable "async", so no one project that use lib Pika can't be launched on Python 3.7a4 --

[issue11849] glibc allocator doesn't release all free()ed memory

Antoine Pitrou added the comment: It's not really a fix, it's an improvement, and as such doesn't belong in 2.7. Using malloc() and free() is not a bug in itself. -- ___ Python tracker

[issue11849] glibc allocator doesn't release all free()ed memory

Bob Kline added the comment: Would it be inappropriate for this fix to be applied to 2.7? -- nosy: +bkline ___ Python tracker ___

[issue32559] logging - public function to get level from name

Raymond Hettinger added the comment: The use case of setting the level by name was already fulfilled in Python 3.2. The logging.setLevel() function takes either an int or a string. -- assignee: -> vinay.sajip nosy: +rhettinger, vinay.sajip priority:

[issue32544] Speed up hasattr(o, name) and getattr(o, name, default)

INADA Naoki added the comment: I run pyperformance. It seems django_template is significant faster. # Without PGO+LTO ./python -m perf compare_to -G --min-speed=2 default.json patched.json Slower (6): - scimark_monte_carlo: 217 ms +- 9 ms -> 237 ms +- 10 ms: 1.09x

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou added the comment: > And all the async file IO APIs I know [1][2][3] have the public API of "just > like regular files, but the blocking methods are async". 99% of the time, > that means TextWrapper and BufferedStream. So I just don't see any way to get > the

[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: Hmm, why did I use "unbuffered" as my term above? That's a very odd name. It's like, exactly the opposite of what we actually want. Clearly I did not think this through properly. Please pretend I said "buffer-only" instead, thanks. > So my

[issue32564] Syntax error on using variable async

Serhiy Storchaka added the comment: See https://docs.python.org/3.7/whatsnew/3.5.html#new-keywords. -- nosy: +serhiy.storchaka ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Simplifying "with"-related opcodes (and perhaps "finally" ones) sounds nice. "try" blocks are already zero-overhead for practical purposes (i.e. I don't think I've met any workload where moving a "try" around did improve performance

[issue32564] Syntax error on using variable async

New submission from Andrew Olefira : In python 3.6 you can use name "async" for variable: >>> class A: ... async = True ... >>> but in python 3.7a4 you catch syntax error: >>> class A: ... async = True File "", line 2 async = True ^

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Apparently PR 5006 has a conflict. Otherwise, is it ready for review? -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: What should be done for PR 5006? Changes of this PR have been minimized for easier review. But many interesting things can made after merging it. For example simplify 'with'-related opcodes. Or implement static blocks (this will

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou added the comment: > Ideally we would be able to do buffer-only reads through all the of the > different read methods (read, readline, readinto, ...), Hmm... We already have non-blocking support in BufferedIOReader, except it *doesn't work*. The problem is,

<    1   2