[issue46527] enumerate no longer accepts iterable keyword argument
New submission from Trey Hunner : While playing around with the main CPython branch against I noticed that enumerate now gives a strange error message when `iterable` is provided as a keyword argument: >>> enumerate(iterable=[]) Traceback (most recent call last): File "", line 1, in TypeError: enumerate() missing required argument 'iterable' When passing an invalid keyword argument (and no positional arguments) an interesting error message is also given: >>> enumerate(hello="world") Traceback (most recent call last): File "", line 1, in TypeError: enumerate() missing required argument 'iterable' The help output still shows that iterable is accepted as either a keyword argument or a positional argument. -- components: Library (Lib) messages: 411695 nosy: trey priority: normal severity: normal status: open title: enumerate no longer accepts iterable keyword argument versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46334] Glossary URLs with anchor link no longer jump to definitions
Trey Hunner added the comment: I just realized those only affects some terms. parameter works: https://docs.python.org/3/glossary.html#term-parameter And LBYL does work but only if LBYL was used: https://docs.python.org/3/glossary.html#term-LBYL The EAFP term does link to #term-LBYL instead of the old #term-lbyl. It looks like the capitalization changed. The search doesn't seem to know that though (the LBYL glossary link at the top is broken): https://docs.python.org/3/search.html?q=lbyl I would vote for changing the link back to lowercase rather than changing the search to link to the new URL. Otherwise links to specific glossary terms scattered around the internet will all link to the top of the glossary page instead. -- ___ Python tracker <https://bugs.python.org/issue46334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46334] Glossary URLs with anchor link no longer jump to definitions
New submission from Trey Hunner : The glossary page allows for anchor links to jump to specific definitions. For example: https://docs.python.org/3.9/glossary.html#term-lbyl will open the glossary page with the web browser showing the LBYL at the top of the page. This no longer works in Python 3.10 and Python 3.11 documentation. https://docs.python.org/3.10/glossary.html#term-lbyl https://docs.python.org/3.11/glossary.html#term-lbyl Opening either of those links in Chrome or Firefox on my machine results in the glossary page being opened without any scrolling (the top of the glossary page is shown rather than the LBYL definition). -- assignee: docs@python components: Documentation messages: 410234 nosy: docs@python, trey priority: normal severity: normal status: open title: Glossary URLs with anchor link no longer jump to definitions type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45897] Frozen dataclasses with slots raise TypeError
New submission from Trey Hunner : When making a dataclass with slots=True and frozen=True, assigning to an invalid attribute raises a TypeError rather than a FrozenInstanceError: >>> from dataclasses import dataclass >>> @dataclass(frozen=True, slots=True) ... class Vector: ... x: float ... y: float ... z: float ... >>> v = Vector(1, 2, 3) >>> v.a = 4 Traceback (most recent call last): File "", line 1, in File "", line 5, in __setattr__ TypeError: super(type, obj): obj must be an instance or subtype of type -- messages: 406973 nosy: trey priority: normal severity: normal status: open title: Frozen dataclasses with slots raise TypeError type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43070] Control keys stop working after pressing Ctrl-C Escape Enter
Trey Hunner added the comment: Thank you Steve and Tadek for confirming that this is a readline feature and for pointing me to the readline manual. The note about an ~/.inputrc file lead me to discover (happily) that I could override this behavior by creating a ~/.inputrc file with the following line in it: "\e\C-M": abort Stop Esc Enter from entering vi mode in Python REPL I'm closing this as "not a bug". -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43070] Control keys stop working after pressing Ctrl-C Escape Enter
Trey Hunner added the comment: I got some help investigating via a Twitter thread on this topic: https://twitter.com/treyhunner/status/1355280273399664642 Here's more context: that combination of keys seems to put readline into vi mode, though it only does so in Python and not inside my system shell. If I type start to type a line of code (say "2+2") and hit Escape and then type vi commands like 0 or $, the cursor will navigate to the beginning/end of the line as expected in vi mode. Ctrl-Alt-L clears the screen and typing "Ctrl-A e" enters back into Emacs readline mode. I can understand how "Ctrl-A v" would cause the Python REPL to enter vi mode, but I don't understand why "Ctrl-C Escape Enter" would cause that. -- ___ Python tracker <https://bugs.python.org/issue43070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43070] Control keys stop working after pressing Ctrl-C Escape Enter
New submission from Trey Hunner : On Ubuntu Linux 18.04 when I run Python from within a terminal, control keys such as Ctrl-L, Ctrl-A, Ctrl-E, and Ctrl-K work as expected. However, if I type Ctrl-C Escape Enter (^C followed by Esc followed by Return), control keys stop working as expected. Ctrl-C still causes KeyboardInterrupt to be printed, but pressing Ctrl-L causes "^L" to be shown and Ctrl-A shows "^A". This happens in Gnome Terminal as well as XTerm both on Ubuntu Linux 18.04. It happens in zsh, bash, tcsh, and sh. I've reproduced this issue in Python 2.7, 3.6, 3.7, 3.8, 3.9, and 3.10. Some of these Python versions I installed via pyenv, some came from the deadsnakes PPA, and some were preinstalled with Ubuntu. -- messages: 385957 nosy: trey priority: normal severity: normal status: open title: Control keys stop working after pressing Ctrl-C Escape Enter type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42354] Tuple unpacking with * causes SyntaxError in with ... as ...
New submission from Trey Hunner : The below code worked on Python 3.5, 3.6, 3.7, and 3.8, but it now crashes on Python 3.9. from contextlib import contextmanager @contextmanager def open_files(names): yield names # This would actually return file objects with open_files(['file1.txt', 'file2.txt']) as (first, *rest): print(first, rest) The error shown is: with open_files(['file1.txt', 'file2.txt']) as (first, *rest): ^ SyntaxError: invalid syntax -- messages: 380932 nosy: trey priority: normal severity: normal status: open title: Tuple unpacking with * causes SyntaxError in with ... as ... type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Trey Hunner added the comment: This is a bug for string comparisons as well. I just had to manually reimplement assertMultiLineEqual (which doesn't call assertSequenceEqual) on one of my test classes to workaround this issue. -- nosy: +trey versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36582] collections.UserString encode method returns a string
New submission from Trey Hunner :
It looks like the encode method for UserString incorrectly wraps its return
value in a str call.
```
>>> from collections import UserString
>>> UserString("hello").encode('utf-8') == b'hello'
False
>>> UserString("hello").encode('utf-8')
"b'hello'"
>>> type(UserString("hello").encode('utf-8'))
```
--
components: Library (Lib)
messages: 339818
nosy: trey
priority: normal
severity: normal
status: open
title: collections.UserString encode method returns a string
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue36582>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33049] itertools.count() confusingly mentions zip() and sequence numbers
New submission from Trey Hunner <trey@truthful.technology>: >From the itertools documentation: >https://docs.python.org/3/library/itertools.html?highlight=itertools#itertools.count > Also, used with zip() to add sequence numbers. I'm not certain what the goal of the original sentence was, but I think it's unclear as currently written. I assume this is what's meant: my_sequence = [1, 2, 3, 4] for i, item in zip(count(1), my_sequence): print(i, item) This is a strange thing to note though because enumerate would be a better use here. my_sequence = [1, 2, 3, 4] for i, item in enumerate(my_sequence, start=1): print(i, item) Maybe what is meant is that count can be used with a step while enumerate cannot? my_sequence = [1, 2, 3, 4] for i, item in zip(count(step=5), my_sequence): print(i, item) If that's the case it seems like step should instead be mentioned there instead of "sequence numbers". -- assignee: docs@python components: Documentation messages: 313606 nosy: docs@python, trey priority: normal severity: normal status: open title: itertools.count() confusingly mentions zip() and sequence numbers type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32915] Running Python 2 with -3 flag doesn't complain about cmp/__cmp__
New submission from Trey Hunner <trey@truthful.technology>: I might be misunderstanding the use of the -3 flag, but it seems like cmp() and __cmp__ should result in warnings being displayed. -- components: 2to3 (2.x to 3.x conversion tool) files: caseless.py messages: 312604 nosy: trey priority: normal severity: normal status: open title: Running Python 2 with -3 flag doesn't complain about cmp/__cmp__ versions: Python 2.7 Added file: https://bugs.python.org/file47459/caseless.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30466] Tutorial doesn't explain the use of classes
Changes by Trey Hunner <trey@truthful.technology>: -- pull_requests: +2766 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30466] Tutorial doesn't explain the use of classes
Changes by Trey Hunner <trey@truthful.technology>: -- pull_requests: +1887 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30466] Tutorial doesn't explain the use of classes
New submission from Trey Hunner: The tutorial page for classes starts with "Compared with other programming languages". While object-oriented programming and classes are popular in many programming languages, not everyone learning about Python's classes is familiar with the concept. I teach both new programmers and programmers who have heard of object-oriented programming but never created a class before. I think the first paragraph on this page should be a brief explanation of the use of classes. It may also be a good idea to have a "Why classes?" section explaining the uses of classes in more detail. -- assignee: docs@python components: Documentation messages: 294409 nosy: docs@python, trey priority: normal severity: normal status: open title: Tutorial doesn't explain the use of classes type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26351] Occasionally check for Ctrl-C in long-running operations like sum
Trey Hunner added the comment: This is a problem I experience occasionally while teaching and while developing teaching curriculum. I tend to close problem windows quickly enough to avoid a computer crash in front of a live audience, but it's still an annoyance to get the REPL state back to the way I had it before killing the process. This mostly happens when I'm teaching iterators or itertools, but occasionally I hit a "Ctrl-C free zone" in other ways. I believe this memory-filling snippet wouldn't respond to Ctrl-C either: x=[0]*2**30 I hadn't thought to report a bug on this because my use seemed niche. I mostly get this error while demonstrating concepts via weird/incorrect code at the REPL. -- nosy: +trey ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
