[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop
Jonathan Fine added the comment: My main concern is that the door not be closed on improving the user experience relating to this behaviour of the compiler. This issue was raised as a bug for the compiler (which is C-coded). I'd be very happy for this issue to be closed as 'not a bug' for the compiler, provided the door is left open for Python-coded improvements for the user experience. I suggest that the issue title be changed to: The two-pass compile(bad_src, ...) sometimes does not report first error in bad_src These two changes to the details of closure would be sufficient to meet my concern. I hope they can be accepted. By the way, I see these improvements being done as a third-party pure-Python module outside Python's Standard Library, at least until they've reached a wide measure of community acceptance. -- ___ Python tracker <https://bugs.python.org/issue46910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop
Jonathan Fine added the comment: Many thanks Pablo for the clear explanation. I'd prefer that the issue remain open, as there's an important user experience issue here. I suspect there are other similar examples of how the compiler error messages could be improved. Here's a change that doesn't seem to be too hard, that could fix the problem at hand. The IndentationError occurred at a known location in the input string. So as part of error reporting truncate the input string and try to compile that. In other words, make a good faith attempt to find an earlier error. I've attached a funny_break_error_fix.py which is a first draft implementation of this idea. Here's the output: === $ python3 funny_break_error_fix.py funny_break_error.py unexpected indent (funny_break_error.py, line 6) Traceback (most recent call last): File "funny_break_error_fix.py", line 3, in compile_fix compile(source, filename, 'exec') File "funny_break_error.py", line 6 else: ^ IndentationError: unexpected indent During handling of the above exception, another exception occurred: Traceback (most recent call last): File "funny_break_error_fix.py", line 18, in compile_fix(src.read(), filename, 'exec') File "funny_break_error_fix.py", line 9, in compile_fix compile(new_source, filename, 'exec') File "funny_break_error.py", line 5 break ^ SyntaxError: 'break' outside loop === And in this case we've got hold of the first error (at the cost of compiling part of the source file twice). Many thanks again for the clear explanation, which I found most helpful when formulating the above fix. -- Added file: https://bugs.python.org/file50656/funny_break_error_fix.py ___ Python tracker <https://bugs.python.org/issue46910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop
New submission from Jonathan Fine :
This arises from a request for help made by Nguyễn Ngọc Tiến to the visually
impaired programmers lists, see
https://www.freelists.org/post/program-l/python,48. Please keep this in mind.
Nguyễn asked for help with the syntax error created by
===
count = 0
while count < 1:
count = count + 1
print(count)
break
else:
print("no break")
===
When I saved this to a file and ran it I got:
===
$ python3.8 funny_break_error.py
File "funny_break_error.py", line 6
else:
^
IndentationError: unexpected indent
===
However, remove the last two lines and you get the more helpful error
===
$ python3.8 funny_break_error.py
File "funny_break_error.py", line 5
break
^
SyntaxError: 'break' outside loop
===
Python3.6 and 3.7 also behave as above.
Note. I've heard that blind Python programmers prefer a single space to denote
indent. I think this is because they hear the leading spaces via a screen
reader, rather than see the indent with their eyes.
--
components: Parser
files: funny_break_error.py
messages: 414424
nosy: jfine2358, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Expect IndentationError, get SyntaxError: 'break' outside loop
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file50655/funny_break_error.py
___
Python tracker
<https://bugs.python.org/issue46910>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44623] help(open('/dev/zero').writelines) gives no help
Jonathan Fine added the comment: I used my default Python, which is Python 3.6. However, with 3.7 and 3.8 I get the same as Paul. So I'm closing this as 'not a bug' (as there's not an already-fixed option for closing). -- resolution: works for me -> not a bug status: pending -> open ___ Python tracker <https://bugs.python.org/issue44623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44623] help(open('/dev/zero').writelines) gives no help
New submission from Jonathan Fine :
On Linux
>>> help(open('/dev/zero').writelines)
gives
However
https://docs.python.org/3/library/io.html#io.IOBase.writelines
gives
Write a list of lines to the stream. Line separators are not added, so it is
usual for each of the lines provided to have a line separator at the end.
See also request that writelines support a line separator.
https://mail.python.org/archives/list/python-id...@python.org/thread/A5FT7SVZBYAJJTIWQFTFUGNSKMVQNPVF/#A5FT7SVZBYAJJTIWQFTFUGNSKMVQNPVF
--
assignee: docs@python
components: Documentation
messages: 397414
nosy: docs@python, jfine2358
priority: normal
severity: normal
status: open
title: help(open('/dev/zero').writelines) gives no help
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue44623>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40028] Math module method to find prime factors for non-negative int n
Jonathan Fine added the comment: A pre-computed table of primes might be better. Of course, how long should the table be. There's an infinity of primes. Consider >>> 2**32 4294967296 This number is approximately 4 * (10**9). According to https://en.wikipedia.org/wiki/Prime_number_theorem, there are 50,847,534 primes less than 10**9. So, very roughly, there are 200,000,000 primes less than 2**32. Thus, storing a list of all these prime numbers as 32 bit unsigned integers would occupy about >>> 200_000_000 / (1024**3) * 4 0.7450580596923828 or in other words 3/4 gigabytes on disk. A binary search into this list, using as starting point the expected location provided by the prime number theorem, might very well require on average less than two block reads into the file that holds the prime number list on disk. And if someone needs to find primes of this size, they've probably got a spare gigabyte or two. I'm naturally inclined to this approach because by mathematical research involves spending gigahertz days computing tables. I then use the tables to examine hypotheses. See https://arxiv.org/abs/1011.4269. This involves subsets of the vertices of the 5-dimensional cube. There are of course 2**32 such subsets. -- nosy: +jfine2358 ___ Python tracker <https://bugs.python.org/issue40028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating literal dict with repeated keys gives no warnings/errors
Jonathan Fine added the comment:
This is was closed and tagged as resolved in 2012. The status has not been
changed since then.
Using dict(a=1, ...) provides a workaround, but only when the keys are valid as
variable names. The general workaround is something like
helper([
(1, 'a'),
(2, 'b'),
#etc
])
The helper is necessary:
>>> [(1, 2)] * 5
[(1, 2), (1, 2), (1, 2), (1, 2), (1, 2)]
>>> dict([(1, 2)] * 5)
{1: 2}
--
___
Python tracker
<https://bugs.python.org/issue16385>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16385] evaluating literal dict with repeated keys gives no warnings/errors
Jonathan Fine added the comment: I mention this issue, and related pages, in [Python-ideas] dict literal allows duplicate keys https://mail.python.org/pipermail/python-ideas/2019-March/055717.html It arises from a discussion of PEP 584 -- Add + and - operators to the built-in dict class. Please send any follow-up to python-ideas (or this issue). -- nosy: +jfine2358 ___ Python tracker <https://bugs.python.org/issue16385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26910] dictionary literal should not allow duplicate keys
Jonathan Fine added the comment: I mention this issue, and related pages, in [Python-ideas] dict literal allows duplicate keys https://mail.python.org/pipermail/python-ideas/2019-March/055717.html It arises from a discussion of PEP 584 -- Add + and - operators to the built-in dict class. Please send any follow-up to python-ideas (or #16385). -- nosy: +jfine2358 ___ Python tracker <https://bugs.python.org/issue26910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35857] Stacktrace shows lines from updated file on disk, not code actually running
Jonathan Fine added the comment: For information - all taken from docs and Lib/*.py https://docs.python.org/3.7/library/traceback.html traceback -- Print or retrieve a stack traceback Source code: Lib/traceback.py === This module provides a standard interface to extract, format and print stack traces of Python programs. It exactly mimics the behavior of the Python interpreter when it prints a stack trace. This is useful when you want to print stack traces under program control, such as in a “wrapper” around the interpreter. === https://github.com/python/cpython/blob/3.7/Lib/traceback.py#L344-L359 === for f, lineno in frame_gen: co = f.f_code filename = co.co_filename name = co.co_name fnames.add(filename) linecache.lazycache(filename, f.f_globals) # Must defer line lookups until we have called checkcache. if capture_locals: f_locals = f.f_locals else: f_locals = None result.append(FrameSummary( filename, lineno, name, lookup_line=False, locals=f_locals)) for filename in fnames: linecache.checkcache(filename) === By the way, here fnames is a set. https://docs.python.org/3.7/library/linecache.html#module-linecache linecache -- Random access to text lines === The linecache module allows one to get any line from a Python source file, while attempting to optimize internally, using a cache, the common case where many lines are read from a single file. This is used by the traceback module to retrieve source lines for inclusion in the formatted traceback. === === linecache.checkcache(filename=None) Check the cache for validity. Use this function if files in the cache may have changed on disk, and you require the updated version. If filename is omitted, it will check all the entries in the cache. linecache.lazycache(filename, module_globals) Capture enough detail about a non-file-based module to permit getting its lines later via getline() even if module_globals is None in the later call. This avoids doing I/O until a line is actually needed, without having to carry the module globals around indefinitely. === -- ___ Python tracker <https://bugs.python.org/issue35857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35857] Stacktrace shows lines from updated file on disk, not code actually running
Jonathan Fine added the comment: The problem, as I understand it, is a mismatch between the code object being executed and the file on disk referred to by the code object. When a module is reloaded it is first recompiled, if the .py file is newer than the .pyc file. (I've tested this at a console.) Suppose wibble.py contains a function fn. Now do import wibble fn = wibble.fn # Modify and save wibble.py reload(wibble) fn() It seems to me that 1) We have a mismatch between fn (in module __main__) and the file on disk. 2) Comparison will show that wibble.pyc is later than wibble.py. 3) There's no reliable way to discover that fn is not the current fn ... 4) ... other than comparing its bytecode with that of the current value of wibble.fn. Regarding (4) there might be another method. But I can't think of one that's reliable. -- nosy: +jfine2358 ___ Python tracker <https://bugs.python.org/issue35857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35698] [statistics] Division by 2 in statistics.median
Jonathan Fine added the comment: I'm still thinking about this. I find Steve's closing of the issue premature, but I'm not going to reverse it. -- ___ Python tracker <https://bugs.python.org/issue35698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35698] Division by 2 in statistics.median
Jonathan Fine added the comment: It might be better in my sample code to write isinstance(p, int) instead of type(p) == int This would fix Rémi's example. (I wanted to avoid thinking about (False // True).) For median([1, 1]), I am not claiming that 1.0 is wrong and 1 is right. I'm not saying the module is broken, only that it can be improved. For median([1, 1]), I believe that 1 is a better answer, particularly for school students. In other words, that making this change would improve Python. As a pure mathematician, to me 1.0 means a number that is close to 1. Whereas 1 means a number that is exactly 1.. -- ___ Python tracker <https://bugs.python.org/issue35698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35698] Division by 2 in statistics.median
Jonathan Fine added the comment: Here's the essence of a patch. Suppose the input is Python integers, and the output is a mathematical integer. In this case we can make the output a Python integer by using the helper function >>> def wibble(p, q): ... if type(p) == type(q) == int and p%q == 0: ... return p // q ... else: ... return p / q ... >>> wibble(4, 2) 2 >>> wibble(3, 2) 1.5 This will also work for average. -- ___ Python tracker <https://bugs.python.org/issue35698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35698] Division by 2 in statistics.median
Jonathan Fine added the comment: I read PEP 450 as saying that statistics.py can be used by "any secondary school student". This is not true for most Python libraries. In this context, the difference between a float and an int is important. Consider statistics.median([2] * n) As a secondary school student, knowing the definition of median, I might expect the value to be 2, for any n > 0. What else could it be. However, the present code gives 2 for n odd, and 2.0 for n even. I think that this issue is best approached by taking the point of view of a secondary school student. Or perhaps even a primary school student who knows fractions. (A teacher might use statistics.py to create learning materials.) By the way, 2 and 2.0 are not interchangeable. For example >>> [1] * 2.0 TypeError: can't multiply sequence by non-int of type 'float' -- ___ Python tracker <https://bugs.python.org/issue35698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35698] Division by 2 in statistics.median
New submission from Jonathan Fine : When len(data) is odd, median returns the average of the two middle values. This average is computed using i = n//2 return (data[i - 1] + data[i])/2 This results in the following behaviour >>> from fractions import Fraction >>> from statistics import median >>> F1 = Fraction(1, 1) >>> median([1]) 1 >>> median([1, 1]) # Example 1. 1.0 >>> median([F1]) Fraction(1, 1) >>> median([F1, F1]) Fraction(1, 1) >>> median([2, 2, 1, F1]) # Example 2. Fraction(3, 2) >>> median([2, 2, F1, 1]) # Example 3. 1.5 Perhaps, when len(data) is odd, it would be better to test the two middle values for equality. This would resolve Example 1. It would not help with Examples 2 and 3, which might not have a satisfactory solution. See also issue 33084. -- messages: 05 nosy: jfine2358 priority: normal severity: normal status: open title: Division by 2 in statistics.median type: behavior ___ Python tracker <https://bugs.python.org/issue35698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33084] Computing median, median_high an median_low in statistics library
Jonathan Fine added the comment: Based on a quick review of the python docs, the bug report, PEP 450 and this thread, I suggest 1. More carefully draw attention to the NaN feature, in the documentation for existing Python versions. 2. Consider revising statistics.py so that it raises an exception, when passed NaN data. This implies dividing this issue into two parts: legacy and future. For more information, see: https://mail.python.org/pipermail/python-ideas/2019-January/054872.html -- nosy: +jfine2358 ___ Python tracker <https://bugs.python.org/issue33084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34431] Docs does not eval allows code object as argument
Jonathan Fine added the comment: This graceful reminder is most welcome. At present, it's not help I'm short of, but time. I've given myself a reminder, to spend time on this before the end of this month (January 2019). Once again, thank you for this reminder. This is something I want to do. It would be my first Python contribution. -- ___ Python tracker <https://bugs.python.org/issue34431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34464] docs: keywords are special - eg constants.html
Jonathan Fine added the comment: I'm happy to work on improving the text here. I'm new to contributing to Python. I'm being mentored to work on #34431. Once I'm done with that, I'll be better placed to contributed to this issue. -- ___ Python tracker <https://bugs.python.org/issue34464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34464] docs: keywords are special - eg constants.html
New submission from Jonathan Fine : The identifiers True, False, None and __debug__ are keywords in the language. For example >>> __debug__ = __debug__ SyntaxError: assignment to keyword 1. The page constants.html incorrectly says then are in the built-in namespace. Some of them were, once. 2. The list keyword.kwlist does not contain __debug__. (Problem in Lib/keyword.py.) 3. https://docs.python.org/3/reference/datamodel.html for None, NotImplemented, etc. 4. There may be other places that need looking at. See also: https://github.com/jfine2358/py-jfine2358/blob/master/docs/none-is-special.md Credit: The __debug__ problem arises from Steve D'Aprano's message https://mail.python.org/pipermail/python-ideas/2018-August/052917.html The std lib contains a test that this correctly raises SyntaxError: def f(*, x=lambda __debug__:0): pass -- assignee: docs@python components: Documentation messages: 323904 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: docs: keywords are special - eg constants.html type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34452] docs: help text for [>>>] toggle always in English
Jonathan Fine added the comment: Thank you. I've raised "The help text for [>>>] toggle always in English" https://github.com/python/python-docs-theme/issues/23 -- ___ Python tracker <https://bugs.python.org/issue34452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34452] docs: help text for [>>>] toggle always in English
New submission from Jonathan Fine : As subject. Background information in #34451. See https://docs.python.org/fr/3/tutorial/introduction.html The hover help text for the [>>>] is in English, not French. Korean and Japanese documentation has the same problem. -- assignee: docs@python components: Documentation messages: 323840 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: docs: help text for [>>>] toggle always in English type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts
New submission from Jonathan Fine : Interactive code examples need the prompt to be stripped, before copy-and-paste. This is explained in https://docs.python.org/3/tutorial/introduction.html But this page does not tell us about the [>>>] prompt-toggle at top of each interactive code example. This caused a user error, reported in https://mail.python.org/pipermail/python-ideas/2018-August/052869.html. The [>>>] toggle isn't in the Python 2.7 docs, so nothing to fix there! -- assignee: docs@python components: Documentation messages: 323839 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: docs: tutorial/introduction doesn't mention toggle of prompts versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34431] Docs does not eval allows code object as argument
Jonathan Fine added the comment: OK. I'll do as you say. I've just signed the CLA. -- ___ Python tracker <https://bugs.python.org/issue34431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34431] Docs does not eval allows code object as argument
Jonathan Fine added the comment: Summary: There's my problem, and others. I'm willing to provide a patch, if supported. There's a gotcha here. I fell into it. The docs for eval state === eval(expression, globals=None, locals=None) The arguments are a string and optional globals and locals. === I read this and concluded, fairly I think, that I'm not allowed to pass in a code object [1]. So I didn't read any further. I'd already got the answer to my question. But I knew that exec would take a code object, so I had doubt, and did my little experiment. I'd prefer something more like exec, which says === This function supports dynamic execution of Python code. object must be either a string or a code object. === There are other problems, such as not agreeing with the help(eval) etc messages (and the still open #22057, #25810): === eval(source, globals=None, locals=None, /) Evaluate the given source in the context of globals and locals. The source may be a string representing a Python expression or a code object as returned by compile(). The globals must be a dictionary and locals can be any mapping, defaulting to the current globals and locals. If only globals is given, locals defaults to it. === exec(source, globals=None, locals=None, /) Execute the given source in the context of globals and locals. The source may be a string representing one or more Python statements or a code object as returned by compile(). The globals must be a dictionary and locals can be any mapping, defaulting to the current globals and locals. If only globals is given, locals defaults to it. === Finally, I'm willing to provide a patch, if supported. (I've not contributed to Python before.) [1] I'd just read the docs for exec, which is up-front about 'string or code'. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue34431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34431] Docs does not eval allows code object as argument
New submission from Jonathan Fine : See https://docs.python.org/3.6/library/functions.html#eval This says the following won't happen. But it does. Python 3.6.2 (default, Jul 29 2017, 00:00:00) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def fn(): print(3); return 4 ... >>> eval(fn.__code__) 3 4 Compare with https://docs.python.org/3.6/library/functions.html#exec Search for eval in title of open issues bring up related #22057 (The doc say all globals are copied on eval(), but only __builtins__ is copied) #25810 (Python 3 documentation for eval is incorrect) -- assignee: docs@python components: Documentation messages: 323716 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: Docs does not eval allows code object as argument versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34398] Docs search does not index glossary items
Jonathan Fine added the comment: Thank you for this, Ammar. Proof of concept solution is good progress. I'm well impressed. The screen shots convince me that it's well worth doing. For me, the one thing that's missing is a link just above the glossary item. Something like "Glossary: iterable". You're probably aware of this, and so far it's only proof-of-concept. Oh, and of course that the links in the displayed item work. My be a gotcha here for links to other glossary items. So, well done, and thank you very much. -- ___ Python tracker <https://bugs.python.org/issue34398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34398] Docs search does not index glossary items
Jonathan Fine added the comment: You're right! Thank you. However, there's still a problem. A user searches for a technical term, and the carefully written glossary entry defining it does not appear. For my search term (iterable), there was a single entry with a link to the Glossary page, whose associated text was simply the first few entries in the glossary. === Glossary ...active shell when entering code for an indented code block or within a pair of matching left and right delimiters (parentheses, square brackets or curly braces). 2to3 A tool that tries to convert Python 2.x code to Pyt... === On a related matter. Sphinx provides an anchor, used for internal navigation with the glossary. But it doesn't provide a permalink to that anchor. Compare https://docs.python.org/3.5/glossary.html#term-iterable https://docs.python.org/3.5/reference/compound_stmts.html#with I think there's a real problem, and that my initial diagnosis was wrong. So I've changed the issue title slightly. (I hope you don't mind.) The problem is, perhaps, that it is the glossary page that is indexed, rather than the glossary items. Another fix would be, as you suggest, pop up at top of results page a glossary item. -- title: Docs search does not index glossary -> Docs search does not index glossary items ___ Python tracker <https://bugs.python.org/issue34398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34398] Docs search does not index glossary
Jonathan Fine added the comment: Good discovery. The glossary uses the RST glossary directive. https://github.com/python/cpython/blob/master/Doc/glossary.rst The Sphinx docs have a glossary, which is indexed by its search. http://www.sphinx-doc.org/en/master/search.html?q=domain So maybe Sphinx already has the functionality we require. Perhaps it's simply a matter of configuring the Python docs to use it. (This is optimism.) -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue34398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34398] Docs search does not index glossary
New submission from Jonathan Fine : The docs contain a very useful page https://docs.python.org/3.5/glossary.html. However, the search feature does not index the glossary. Thus, the search https://docs.python.org/3.5/search.html?q=iterable does not produce the helpful glossary entry === iterable An object capable of returning its members one at a time. Examples of iterables include all sequence types (such as list, str, and tuple) and some non-sequence types like dict, file objects, and objects of any [...] === #788509 is the only docs issue I could find, whose title contains glossary. It gives insight into the thoughts then about the tutorial. In msg44460 Skip Montaro says (1) that the glossary is "for the tutorial", and (2) he'd like to improve links into the tutorial. I suggest that part of the fix for this issue is on the home page page Glossary in the first grouping "Parts of the documentation." -- assignee: docs@python components: Documentation messages: 323503 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: Docs search does not index glossary type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34237] faq/design: PEP 572 adds assignment expressions
Jonathan Fine added the comment: I'm sorry. I apologise. I'm being a bit stupid. Everything is fine. Nothing to do. In case you care, here's the situation. Python 3.8 is in development, and not yet released. Somehow, I'd got it into my mind that it had already been released. So the PEP 572 header is correct. The PEP status is accepted, the feature is in development (including documentation), and all being well the feature and the documentation will appear in Python3.8. By the way, according to https://www.python.org/dev/peps/pep-0569/#id5, the first alpha is due 2019-01-27. So please, all of you, accept my apologies. -- ___ Python tracker <https://bugs.python.org/issue34237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34237] faq/design: PEP 572 adds assignment expressions
Jonathan Fine added the comment: First, I'm delighted that the current docs are in fact correct regarding assignment expressions. (I should have said this earlier.) I'm happy to wait for the implementation to land. (And if you like, I'm willing to help with the documentation. I seem to have an eye for detail.) Whether or not mine was the only my mistake, I was misled by the PEP 572 header. (And perhaps Vadim was also - msg322479.) This issue is, rightly, closed. Perhaps the discussion should continue in a new issue? And without Chris, if he doesn't want to be involved. Perhaps it's a matter for the release manager? Or perhaps having Python-Version:3.8 in the PEP remain until the change lands (and then both Status and Python-Version will be changed). I'm new here. I'm happy for someone else to decide. No action is one option. -- ___ Python tracker <https://bugs.python.org/issue34237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34237] faq/design: PEP 572 adds assignment expressions
Jonathan Fine added the comment: My mistake. But not mine only. According to https://www.python.org/dev/peps/pep-0572/ the PEP is Python-Version: 3.8 I took this to mean that it had been implemented in Python 3.8. Reading the PEP more closely, it also says Status: Accepted. According to https://www.python.org/dev/peps/pep-0001/#pep-header-preamble each PEP can have an optional Python-Version, which is "described below". I thus find === Standards Track PEPs will typically have a Python-Version header which indicates the version of Python that the feature will be released with. === I seems to me that there is a bug in the PEP, perhaps caused either by a failure to increment its Python-Version as part of the release of Python 3.8, or the PEP itself providing too early the optional Python-Version. I'll email Chris Angelico about this. I'm very happy for the issue to remain closed. -- ___ Python tracker <https://bugs.python.org/issue34237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25461] Unclear language (the word ineffective) in the documentation for os.walk
Change by Jonathan Fine : -- nosy: +jfine2358 ___ Python tracker <https://bugs.python.org/issue25461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34237] faq/design: PEP 572 adds assignment expressions
New submission from Jonathan Fine :
The title says it all.
faq/design: PEP 572 adds assignment expressions
https://docs.python.org/3.8/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression
[Can't use] this C idiom:
while (line = readline(f)) {
// do something with line
}
https://www.python.org/dev/peps/pep-0572/
while chunk := file.read(8192):
process(chunk)
--
assignee: docs@python
components: Documentation
messages: 322430
nosy: docs@python, jfine2358
priority: normal
severity: normal
status: open
title: faq/design: PEP 572 adds assignment expressions
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue34237>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
