[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter
Change by Malcolm Smith : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue31196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter
Malcolm Smith added the comment: I think it's unlikely that anyone is depending on the ability to enter blank lines in a "try" block in an InteractiveConsole, especially when blank lines terminate the input in almost every other context. Conversely, everyone who's ever entered a multi-line statement into a Python console knows that blank lines usually terminate the input. And they may have gotten into the habit, as I did, of using a blank line to abandon an incomplete input, and they'll be surprised if it doesn't work in this context. On further experimentation, this also affects "def" statements, but only when the blank line is at the start of the block, causing the statement to be syntactically incomplete. Native interpreter: >>> def f(): ... File "", line 2 ^ IndentationError: expected an indented block after function definition on line 1 InteractiveConsole: >>> def f(): ... ... ... pass ... >>> So I think the current behavior is likely to annoy a much larger number of people, but whoever's responsible for this part of the standard library will have to judge that for themselves. -- ___ Python tracker <https://bugs.python.org/issue31196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter
Malcolm Smith added the comment: I agree that both behaviors are reasonable. However, the InteractiveConsole documentation says it should "closely emulate the behavior of the interactive Python interpreter". Since people are familiar with the native interpreter, any difference in behavior is potentially annoying and could throw off somebody's flow. So I think the InteractiveConsole should be changed to match the native interpreter. Like the native interpreter, InteractiveConsole allows other multi-line blocks to be terminated with a blank line: >>> def foo(x): ... pass ... >>> for x in [1,2,3]: ... pass ... >>> I guess the reason why "try" is different is that a "try" block isn't a complete statement on its own. If you follow it with an "except" block, then that can indeed be terminated with a blank line. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue31196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34931] os.path.splitext with more dots
Malcolm Smith added the comment:
> Try for example create/rename .somename.jpg file in Ubuntu.
> It is normal image with .jpg extension. You could open it etc.
>
> You can't use standard python splitext() function to detect extension.
Yes you can (Python 3.8.2):
>>> splitext(".somename.jpg")
('.somename', '.jpg')
Only leading dots are treated specially. If there are non-leading dots later in
the name, then the filename will be split at the last one.
So the only remaining question is weird filenames like ".jpg". There's no
way to know whether that's supposed to be a name with an extension, or a
dot-file with multiple leading dots. Either choice would be reasonable, but
we've already gone with the second one.
Maybe sometimes you might prefer the other way, but such filenames are so rare
that I can't imagine we'd ever add an option for this. So I think this issue
can be closed.
--
nosy: +Malcolm Smith
___
Python tracker
<https://bugs.python.org/issue34931>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33689] Blank lines in .pth file cause a duplicate sys.path entry
Malcolm Smith added the comment: It's definitely a bug and not a documentation lapse. There's no reason why blank lines should have that effect, and no indication in the code that this was intentional. -- ___ Python tracker <https://bugs.python.org/issue33689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34271] Please support logging of SSL master secret by env variable SSLKEYLOGFILE
Malcolm Smith added the comment: It looks like this has now been done and released. Can the issue be closed? -- nosy: +Malcolm Smith ___ Python tracker <https://bugs.python.org/issue34271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34592] cdll.LoadLibrary allows None as an argument
Malcolm Smith added the comment: This isn't documented, but CDLL(None) is translated to dlopen(NULL), which "causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL" (https://linux.die.net/man/3/dlopen). This is sometimes useful because it lets you look up a symbol in an already-loaded library without needing to give the library's name. For example: >>> import ctypes >>> dll = ctypes.CDLL(None) >>> dll.printf <_FuncPtr object at 0x7f3427d547c0> >>> dll.PyObject_Str <_FuncPtr object at 0x7f3427d54880> -- nosy: +Malcolm Smith ___ Python tracker <https://bugs.python.org/issue34592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10948] Trouble with dir_util created dir cache
Malcolm Smith added the comment: Please reopen this issue. The distutils2 project has now been abandoned, so that's no longer a justification for taking no action. At the very least, the documentation should be fixed to either warn about this surprising behavior, or make it clear that the the dir_util functions are for distutils internal use only. -- nosy: +Malcolm Smith versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue10948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29326] Blank lines in ._pth file are not ignored
Malcolm Smith added the comment: FYI: I have created issue 33689 for the non-Windows-specific issue. -- ___ Python tracker <https://bugs.python.org/issue29326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33689] Blank lines in .pth file cause a duplicate sys.path entry
New submission from Malcolm Smith : The `site` module documentation says that in .pth files, "Blank lines and lines beginning with # are skipped.". However, the implementation does not actually skip blank lines. It then joins the empty string to the site-packages directory, resulting in the site-packages directory being added to sys.path a second time. Example: $ python -c 'import sys; print(sys.path)' ['', '/home/smith/.virtualenvs/foo/lib/python36.zip', '/home/smith/.virtualenvs/foo/lib/python3.6', '/home/smith/.virtualenvs/foo/lib/python3.6/lib-dynload', '/usr/lib/python3.6', '/home/smith/.virtualenvs/foo/lib/python3.6/site-packages'] $ echo > /home/smith/.virtualenvs/foo/lib/python3.6/site-packages/test.pth $ python -c 'import sys; print(sys.path)' ['', '/home/smith/.virtualenvs/foo/lib/python36.zip', '/home/smith/.virtualenvs/foo/lib/python3.6', '/home/smith/.virtualenvs/foo/lib/python3.6/lib-dynload', '/usr/lib/python3.6', '/home/smith/.virtualenvs/foo/lib/python3.6/site-packages', '/home/smith/.virtualenvs/foo/lib/python3.6/site-packages'] A patch fixing this is attached to issue 29326, but was ignored when that issue turned out to be caused by something else. -- components: Library (Lib) messages: 318137 nosy: Malcolm Smith priority: normal severity: normal status: open title: Blank lines in .pth file cause a duplicate sys.path entry type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29326] Blank lines in ._pth file are not ignored
Malcolm Smith added the comment: > I'm not aware of any such issue with .pth files - the underscore in ._pth is > deliberate. An identical issue *does* exist for .pth files. As you can see from examining site.addpackage, it does not ignore blank lines as the documentation says. Ammar's patch should also be applied. -- nosy: +Malcolm Smith ___ Python tracker <https://bugs.python.org/issue29326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32640] Python 2.7 str.join documentation is incorrect
New submission from Malcolm Smith <malcolm.sm...@gmail.com>: At some point the Python 3 documentation of str.join has been copied to Python 2. This includes the sentence "A TypeError will be raised if there are any non-string values in iterable, including bytes objects." The second half of this sentence is wrong for Python 2. Not only is there no "bytes" type in Python 2, but join() in this version will happily join any mixture of unicode and (byte-)str objects, producing unicode output if any of the items (or separator) were unicode. https://docs.python.org/2/library/stdtypes.html#str.join -- assignee: docs@python components: Documentation messages: 310525 nosy: Malcolm Smith, docs@python priority: normal severity: normal status: open title: Python 2.7 str.join documentation is incorrect type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32170] Contrary to documentation, ZipFile.extract does not extract timestamps or other metadata
Malcolm Smith <malcolm.sm...@gmail.com> added the comment: Related: Issue15795 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32170] Contrary to documentation, ZipFile.extract does not extract timestamps or other metadata
New submission from Malcolm Smith <malcolm.sm...@gmail.com>: The documentation explicitly says "file information is extracted as accurately as possible". But the `zipfile` module doesn't actually extract any metadata at all. I assume this text was copied and pasted from the `tarfile` module, which does implement this. Fixing the code is preferred to fixing the documentation. -- components: Library (Lib) messages: 307255 nosy: Malcolm Smith priority: normal severity: normal status: open title: Contrary to documentation, ZipFile.extract does not extract timestamps or other metadata type: behavior versions: Python 2.7, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31196] Blank line inconsistency between InteractiveConsole and standard interpreter
New submission from Malcolm Smith: The standard interpreter is more eager to give an error on incomplete input, while the InteractiveConsole will keep on prompting for more: Python 3.5.3 (default, Apr 10 2017, 07:53:16) [GCC 6.3.0 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> try: ... File "", line 2 ^ IndentationError: expected an indented block >>> import code >>> code.interact() Python 3.5.3 (default, Apr 10 2017, 07:53:16) [GCC 6.3.0 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> try: ... ... ... ... The InteractiveConsole isn't totally wrong here, because after all, a blank line in this position is syntactically correct. But the inconsistency is confusing. -- components: Library (Lib) messages: 300230 nosy: Malcolm Smith priority: normal severity: normal status: open title: Blank line inconsistency between InteractiveConsole and standard interpreter type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23674] super() documentation isn't very clear
Malcolm Smith added the comment: I agree that the first two paragraphs are confusing. It's clearly not true to say "The search order is same as that used by getattr() except that the type itself is skipped", because as noted above, everything *earlier* than the type in the MRO is also skipped. The second paragraph then goes on to imply that super() uses the MRO of its first argument, which contradicts the first paragraph, and apparently isn't true either. Raymond explained the actual behavior quite clearly in his comment of 2015-03-15 21:34, and that's what the documentation should do as well. -- nosy: +Malcolm Smith ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15360] Behavior of assigning to __dict__ is not documented
Changes by Malcolm Smith <malcolm.sm...@gmail.com>: -- nosy: +Malcolm Smith ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30840] Contrary to documentation, relative imports cannot pass through the top level
New submission from Malcolm Smith: https://docs.python.org/3/reference/simple_stmts.html#the-import-statement defers the full specification of relative imports to PEP 328. PEP 328 gives the example "from ...sys import path" in a second-level package, and notes "while that last case is legal, it is certainly discouraged". However, in the current implementation it actually isn't legal. Using a stdlib second-level package to test: Python 3.5.3 (default, Apr 10 2017, 07:53:16) [GCC 6.3.0 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import xml.dom >>> __package__ = "xml.dom" >>> from . import minidom # Works fine >>> from ...sys import path Traceback (most recent call last): File "", line 1, in ValueError: attempted relative import beyond top-level package Either the documentation or the implementation should be fixed. -- components: Interpreter Core messages: 297608 nosy: Malcolm Smith priority: normal severity: normal status: open title: Contrary to documentation, relative imports cannot pass through the top level type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30372] Status of __builtins__ is not totally clear
New submission from Malcolm Smith: https://docs.python.org/3.6/reference/executionmodel.html#builtins-and-restricted-execution describes the various things you can do with __builtins__, but then says "Users should not touch __builtins__; it is strictly an implementation detail." If this is so, the entire section should be marked "CPython implementation detail", not just that last paragraph. Elsewhere, https://docs.python.org/3.6/reference/import.html#replacing-the-standard-import-system suggests that the __import__ function could be replaced "at the module level to only alter the behaviour of import statements within that module". Is there any way of doing this other than manipulating the module's __builtins__? If not, this is encouraging the programmer to rely on a CPython implementation detail without marking it as such. -- assignee: docs@python components: Documentation messages: 293722 nosy: Malcolm Smith, docs@python priority: normal severity: normal status: open title: Status of __builtins__ is not totally clear versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30372> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23662] Cookie.domain is undocumented
New submission from Malcolm Smith: This is a fundamental attribute of a cookie, which will be set even if the server doesn't specify it, yet it doesn't appear in the documentation either of 2.x cookielib or 3.x http.cookiejar. -- assignee: docs@python components: Documentation messages: 238087 nosy: Malcolm Smith, docs@python priority: normal severity: normal status: open title: Cookie.domain is undocumented versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
