[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Jesse Silverman added the comment: As Andre noted, it is good in IDLE. I also realize how convenient it is to read the real docs from there. I learned a lot about the state of console programming on Windows, in and out of Python, but I have no problem using IDLE when on Windows. -- ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Jesse Silverman added the comment: "more.com" uses the console input codepage to decode the file, so a workaround is to run `chcp.com 65001` and run Python in UTF-8 mode, e.g. `py -X utf8=1`. Since reading non-ASCII UTF-8 is broken, you'll have to switch back to the old input codepage if you need to enter non-ASCII characters in an app that reads from the console via ReadFile or ReadConsoleA. Confirmed that this workaround done in Windows Terminal causes all mojibake to immediately evaporate, leaving me with the most readable and enjoyable more/console experience I have ever had since first hitting a spacebar on MS-DOS. (Windows Terminal and the open-sourcing of the CONSOLE code is in a three-way tie with open-sourcing of .Net Core and the C++ STL for changing how I feel about Windows. I keep finding new reasons to love it, except for reading non-ASCII UTF-8 being broken which I just learned about today.) -- ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Jesse Silverman added the comment: Thank you so much Inada and Eryk and Steve! I was one of the people who mistakenly thought that Python 3 operating in the new Windows Terminal was going to magically leave us sitting happily in completely UTF-8 compatible territory on Windows, not realizing the complex long-term dependencies and regressions that still remain problematic. I had spent a lot of time paying attention to the Python 2 vs. 3 debates with people shouting "I don't care about Unicode!" and mistook dedication to preventing regressions and breakages for a lesser appreciation of the value of UTF-8 support. I have been schooled. We all want the same thing, but getting there on Windows from where we are at the moment remains non-trivial. Heartfelt appreciation to all on the front lines of dealing with this complex and sticky situation. ❤️❤️❤️ Also, much love to those who had put in the work to have much more help than I realized existed even when one finds oneself isolated on a single disconnected machine with only the standard docs as a guide吝 -- I didn't realize the pages I found mojibake on even existed until this weekend. -- ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Jesse Silverman added the comment: I looked around some more and it definitely is not just one isolated instance. I noted a similar issue on the lines from CLASSES topic pasted here. I think it is all usages of the ellipsis in the context of the help text? Maybe also fancy quote marks that didn't survive the jump from ASCII to Unicode? And some fancy dashes. The theme of my day was excitement at how much more docs and help ship than I had realized with the most basic Python install and thus are at my fingertips anywhere, everywhere, internet access or not. This mars that exuberance only slightly. help> CLASSES The standard type hierarchy *** Below is a list of the types that are built into Python. Extension modules (written in C, Java, or other languages, depending on the implementation) can define additional types. Future versions of Python may add types to the type hierarchy (e.g., rational numbers, efficiently stored arrays of integers, etc.), although such additions will often be provided via the standard library instead. Some of the type descriptions below contain a paragraph listing ΓÇÿspecial attributes.ΓÇÖ These are attributes that provide access to the ... methodΓÇÖs documentation (same as "__func__.__doc__"); "__name__" ... dictionary containing the classΓÇÖs namespace; "__bases__" is a tuple containing the base classes, in the order of their occurrence in the base class list; "__doc__" is the classΓÇÖs documentation string, ΓÇ£ClassesΓÇ¥. See section Implementing Descriptors for another way -- ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
New submission from Jesse Silverman : I didn't know whether to file this under DOCUMENTATION or WINDOWS. I recently discovered the joys of the interactive help in the REPL, rather than just help(whatever). I was exploring the topics and noticed multiple encoding or rendering errors. I realized I stupidly wasn't using the Windows Terminal program but the default console. I addressed that and they persisted in Windows Terminal. I upgraded from 3.9.1 to 3.9.5...same deal. I tried running: Set-Item -Path Env:PYTHONUTF8 -Value 1 before starting the REPL, still no dice. I confirmed this worked in the same session: >>> ustr2='ʑʒʓʔʕʗʘʙʚʛʜʝʞ' >>> ustr2 'ʑʒʓʔʕʗʘʙʚʛʜʝʞ' It does. The help stuff that doesn't render correctly is under topic COMPARISON: lines 20, 21 and 25 of this output contain head-scratch-inducing mystery characters: help> COMPARISON Comparisons *** Unlike C, all comparison operations in Python have the same priority, which is lower than that of any arithmetic, shifting or bitwise operation. Also unlike C, expressions like "a < b < c" have the interpretation that is conventional in mathematics: comparison::= or_expr (comp_operator or_expr)* comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "!=" | "is" ["not"] | ["not"] "in" Comparisons yield boolean values: "True" or "False". Comparisons can be chained arbitrarily, e.g., "x < y <= z" is equivalent to "x < y and y <= z", except that "y" is evaluated only once (but in both cases "z" is not evaluated at all when "x < y" is found to be false). Formally, if *a*, *b*, *c*, ΓǪ, *y*, *z* are expressions and *op1*, *op2*, ΓǪ, *opN* are comparison operators, then "a op1 b op2 c ... y opN z" is equivalent to "a op1 b and b op2 c and ... y opN z", except that each expression is evaluated at most once. Note that "a op1 b op2 c" doesnΓÇÖt imply any kind of comparison between *a* and *c*, so that, e.g., "x < y > z" is perfectly legal (though perhaps not pretty). That is: ΓǪ, ΓǪ, ΓÇÖ em-dash or ellipsis might be involved somehow...maybe fancy apostrophe? My current guess is that it isn't about rendering anymore, because something went awry further upstream? Thanks! -- assignee: docs@python components: Documentation messages: 394817 nosy: docs@python, jessevsilverman priority: normal severity: normal status: open title: Is there a mojibake problem rendering interactive help in the REPL on Windows? type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43056] Use of dicts in 4.2 and 4.7 of Python tutorial a bit confusing
Jesse Silverman added the comment: Agreed with the exception that I'd like to review whether the forward reference to dict in the tutorial might be better suited to people working thru the tutorial than the current forward reference to the real docs. I got to take a look at Eric Matthes' excellent "Python Crash Course". He avoids this by treating function definitions only after introducing both tuples and dicts, rather than together with simple control flow within a function. That would clearly be a re-org that is way out of scope of a bug report. So, if someone compares the potential forward reference to the dict section of the tutorial rather than the current forward reference to the language reference in light of where the tutorial audience is expected to be at when reading this section, I am good with closing it. -- ___ Python tracker <https://bugs.python.org/issue43056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43034] Python tutorial misleads users about floor division behavior
Jesse Silverman added the comment: I understand and agree with both comments. I will confirm that a substantial number of people think -17 // 3 yields -5.0, so when I saw this I wondered if it reinforced that common misconception. I was curious enough to not just confirm in the actual docs not only that -17 // 3 == -6.0 but learned why it does so. I would be happy to see any of Terry's three suggestions added, with the first one adding the most bang for the buck (if someone is surprised to see -6.0 there, they can go look up why). -- ___ Python tracker <https://bugs.python.org/issue43034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43042] Delete or merge redundant tutorial sentence.
Jesse Silverman added the comment: Yes, your takeaway was what precisely what I was getting at. I sounded unsure because I was unsure. In reality, it doesn't matter whether a different function is being called or one is calling itself, the current wording suggests that it might. -- ___ Python tracker <https://bugs.python.org/issue43042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43056] Use of dicts in sections 4.2 and 4.7 of Python tutorial a bit confusing
New submission from Jesse Silverman : The Python tutorial was not my first introduction to Python, but I see things in sections 4.2 and 4.7 that likely would have confused me a lot if it was. In 4.2 near the end, we have great advice about how to avoid problems with modifying a collection while iterating thru it. Unfortunately, it both makes use of a dict despite not having introduced it before at all within the tutorial (I wasn't shocked because it was NOT my first introduction to Python) and in fact, the .items() method which is beautifully explained in section 5.6, which hasn't been read yet. I got thru it a bit shakily, and in a reference, rather than an introductory tutorial, it is quite literally impossible to present everything in a strict sequence, but I would definitely have been thrown for a loop if it was actually my first introduction to Python. All was good again until I got to section 4.7.2, where I was again glad I had previously consumed tutorial materials concerning dict. There is a forward reference to: https://docs.python.org/3.9/library/stdtypes.html#typesmapping Which every Python programmer should undoubtedly be familiar with eventually, but "why not?" to the more novice-friendly: https://docs.python.org/3.9/tutorial/datastructures.html#dictionaries The forward reference from this section to tuples in section 5 of the tutorial suggests that this might have been appropriate as well. The dict, the tuple and parameter passing are all very basic topics indeed, but I would have found 4.7 very rough going if I had no prior exposure to dict and tuple. This isn't a complaint demanding a refund for the cost of the tutorial, so much as an indication of where I think true novices attempting to follow the tutorial in sequence would likely be thrown for a loop. I understand there is a healthy ecosystem of free and paid introductory tutorial material for Python, as evidenced by the fact that I was only working thru the tutorial just now, having been referred to it as a pre-req for other material I will be moving on to soon. -- assignee: docs@python components: Documentation messages: 385870 nosy: docs@python, jessevsilverman priority: normal severity: normal status: open title: Use of dicts in sections 4.2 and 4.7 of Python tutorial a bit confusing versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43043] Python tutorial could make rules for default argument definition clearer
New submission from Jesse Silverman :
I love the tutorial, but have been pointing out things I only knew from brutal
experience, other tutorials, reasoning from other languages I know better, or
looking things up. I only mention them if they seem in scope and at the same
level of the material which is presented.
Regarding 4.7.1. Default Argument Values of the excellent Python tutorial:
I guessed that I would see the behavior shown below from my understanding of
default arguments in several other languages. I did not read anything in this
tutorial section that would lead me to conclude this, and other things
mentioned in this section are neither much more or less subtle, more or less
obvious, or more or less important.
PS F:\PythonCode> py VarArgs.py
File "F:\PythonCode\VarArgs.py", line 1
def varArgs(quote, footnote='', times):
^
SyntaxError: non-default argument follows default argument
Most introductions to default argument definition in other languages go out of
their way to highlight that the default parameters can be only the last N of
them, and that all required ones must come first.
Python is intended to be accessible to people no more clever than the other
languages intend, so tho it seems obvious to me that they must only come after
all required arguments, I remember when it was not obvious (and fortunately the
tutorials I read in the past for other languages belabored the point).
The explanatory text of:
giving one of the optional arguments: ask_ok('OK to overwrite the file?', 2)
as it merely says "one of", rather than "the first of" led me to wonder if
Python was somehow more flexible/better at mind-reading than the languages I
already know well that require all default args to be trailing, and to only let
you default the last one, two, or ... N. The results of the experiment shown
above demonstrate it is similar to the behavior in other languages in this
regard.
I deeply appreciate the information about when the default arguments get
evaluated, which is highly relevant and is not something I would have picked up
on from other languages I've used.
A simple line stating that "any default arguments must follow any required
arguments in the definition" and something like "on calls, optional arguments
may only be omitted from the end of the parameter list, they can't simply be
skipped" would be awesome.
I am not sure whether or not this is made perfectly clear in the next section,
which has a lot of other new and interesting ideas flying around in it as well,
besides this one.
--
assignee: docs@python
components: Documentation
messages: 385813
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Python tutorial could make rules for default argument definition clearer
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43043>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43042] tutorial ambiguous about creation of local symbol table for recursive calls
New submission from Jesse Silverman : In section 4.6 of the tutorial, we find: "When a function calls another function, a new local symbol table is created for that call." Now, perhaps because we were just looking at a function that people will often ask you to write both recursively and non-recursively and then ask which one you would use and why...I was thinking "Wait -- when a function calls itself recursively, obviously they need a new local symbol table or local variables won't work??" I may be confused, in which case the doc is fine and I personally need to better understand the moral equivalent of activation record / stack frame in Python. If I am not, given that recursion isn't much more computer science oriented or obscure than Fibonacci sequences, could it not be worth the investment of a few extra words as: "When a function calls another function, or calls itself recursively, a new local symbol table is created for that call." -- assignee: docs@python components: Documentation messages: 385800 nosy: docs@python, jessevsilverman priority: normal severity: normal status: open title: tutorial ambiguous about creation of local symbol table for recursive calls versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43034] Python tutorial misleads users about floor division behavior
New submission from Jesse Silverman : I had never worked thru the Python tutorial, it's kind of awesome. I noticed multiple independent presenters incorrectly describe the behavior of floor division when the signs of the operands don't match. Not just sloppy ones, some who are usually pretty careful -- people forget. I found it odd. Today I read: https://docs.python.org/3.9/tutorial/introduction.html#using-python-as-a-calculator 'Division (/) always returns a float. To do floor division and get an integer result (discarding any fractional result) you can use the // operator; to calculate the remainder you can use %:' I know what they mean (there will never be a non-zero fractional component in the result) however, stating that it "discards any fraction result" explicitly suggests that it will round towards zero for all results. The name of the operator tells us the true story, as does a test, it rounds towards negative infinity for all results. Hopefully all the people using Python to treat cancer, fly to Mars and run power plants know what the behavior is. However, anecdotally, I have seen evidence that generally cautious, fairly-detail oriented programmers seem to forget the details of the behavior, this is one place in the docs from which many people first learn about the floor division operator and this page would lead me to believe it operates differently than it does in reality. If the words right there don't get changed, or the example of -10/3 doesn't get added, would this be a good excuse for a third footnote? I would actually wish for both the wording to be changed and to show an example like -10 / 3, tho admittedly I came from an Engineering background so I am always worried someone's going to blow up somewhere... Deepest regards for everyone who gets to regularly close the complaints about floor division working as designed and documented -- but not quite documented on this page which more people may read than others covering the operator. -- assignee: docs@python components: Documentation messages: 385746 nosy: docs@python, jessevsilverman priority: normal severity: normal status: open title: Python tutorial misleads users about floor division behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
