[issue34105] test_socket.test_host_resolution_bad_address fails on Mac OS X 10.13.6
Lysandros Nikolaou added the comment: Is this expected behaviour, should the tests be changes, or is it a bug? -- ___ Python tracker <https://bugs.python.org/issue34105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34324] Doc README wrong directory name for vent
New submission from Lysandros Nikolaou : In the Doc README there is the following sentence after the make venv command: Assuming the virtual environment was created in the env directory (the default; configurable with the VENVDIR variable) Should't it be venv directory instead? In the makefile the VENVDIR variable is set to venv by default. -- assignee: docs@python components: Documentation messages: 322997 nosy: docs@python, lys.nikolaou priority: normal severity: normal status: open title: Doc README wrong directory name for vent versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34324] Doc README wrong directory name for venv
Change by Lysandros Nikolaou : -- title: Doc README wrong directory name for vent -> Doc README wrong directory name for venv ___ Python tracker <https://bugs.python.org/issue34324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34105] test_socket.test_host_resolution_bad_address fails on Mac OS X 10.13.6
Lysandros Nikolaou added the comment: When running the terminal command host '0.1.1.~1' I get the following output: 0.1.1.~1 has address 62.138.239.45 0.1.1.~1 has address 62.138.238.45 Host 0.1.1.~1 not found: 3(NXDOMAIN) Host 0.1.1.~1 not found: 3(NXDOMAIN) If I ping the above IP address 62.138.239.45, it does not respond. -- ___ Python tracker <https://bugs.python.org/issue34105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34105] test_socket.test_host_resolution_bad_address fails on Mac OS X 10.13.6
New submission from Lysandros Nikolaou :
On my Mac OS X 10.13.6 system test_socket.test_host_resolution_bad_address
fails with the following error:
==
FAIL: test_host_resolution_bad_address (test.test_socket.GeneralModuleTests)
--
Traceback (most recent call last):
File "/path/to/cpython/Lib/test/test_socket.py", line 897, in
test_host_resolution_bad_address
socket.gethostbyname(addr)
AssertionError: OSError not raised : 0.1.1.~1
--
Ran 555 tests in 24.950s
FAILED (failures=1, skipped=141)
/path/to/cpython/Lib/test/test_socket.py:2345: RuntimeWarning: received
malformed or improperly-truncated ancillary data
result = sock.recvmsg(bufsize, *args)
/path/to/cpython/Lib/test/test_socket.py:2436: RuntimeWarning: received
malformed or improperly-truncated ancillary data
result = sock.recvmsg_into([buf], *args)
test test_socket failed
== Tests result: FAILURE ==
1 test failed:
test_socket
Total duration: 25 sec 423 ms
Tests result: FAILURE
When I manually run socket.gethostbyname('0.1.1.~1'), it returns an IP address,
no exception thrown.
--
components: Tests
messages: 321575
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: test_socket.test_host_resolution_bad_address fails on Mac OS X 10.13.6
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue34105>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34088] [EASY] sndhdr.what() throws exceptions on unknown files
Lysandros Nikolaou added the comment: Upon checking to see where the RuntimeError is coming from, I noticed that there is some notorious behaviour in chunk.py. If one runs python with the exact same parameters as Jussi Judin did in their first case and after stepping through the call stack until Chunk/skip is reached, there is a call to Chunk/seek. On the time of the call size_read has the value 16, whereas within the seek method it has the value 28. Is this intended? If so, where is that implemented? I cannot figure out why this is happening. The following is my pdb output. > cpython/Lib/chunk.py(160)skip() -> self.file.seek(n, 1) (Pdb) p self.size_read 16 (Pdb) s --Call-- > cpython/Lib/chunk.py(98)seek() -> def seek(self, pos, whence=0): (Pdb) p self.size_read 28 -- ___ Python tracker <https://bugs.python.org/issue34088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34088] [EASY] sndhdr.what() throws exceptions on unknown files
Lysandros Nikolaou added the comment: Will you make a PR or shall I try to fix this? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue34088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34839] doctest: Change example under warnings section
Lysandros Nikolaou added the comment: I would be happy to change this. I will submit a PR ASAP. -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue34839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35075] Doc: pprint example uses dead URL
Lysandros Nikolaou added the comment: Also this throws a TypeError, because http_info.get_content_charset() returns None with the new link. I think, this should be fixed as well. -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue35075> ___ ___ 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
Lysandros Nikolaou added the comment: IMHO this is not a bug. Every file starting with a dot is hidden by default, so this is somewhat correct behaviour. Since it is documented correctly I don't this something needs to change here. Yet again, could someone more experienced offer their opinion as well? -- nosy: +lys.nikolaou ___ 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
[issue32804] urllib.retrieve documentation doesn't mention context parameter
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +9521 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+
Lysandros Nikolaou added the comment: Shall I create a PR for this? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue30410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35096] Change _PY_VERSION to derive from sys.version_info in sysconfig
New submission from Lysandros Nikolaou : In sysconfig.py there is a comment starting with FIXME that states that _PY_VERSION should get its value from sys.version_info instead of sys.version, because it is an implementation detail. Should this be changed? If so, I would like to create a PR. -- messages: 328769 nosy: lys.nikolaou priority: normal severity: normal status: open title: Change _PY_VERSION to derive from sys.version_info in sysconfig versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21263] test_gdb failures on os x 10.9.2
Lysandros Nikolaou added the comment: I am trying to create a PR for this and was thinking of somehow updating test.support, in order for someone to be able to find out what compiler was used to build python. Would that make sense? Also, in case this is indeed something we'd like in test.support, what would be the correct sysconfig variables to read, in order to find that out? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue21263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +9575 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue30410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24916] In sysconfig, don't rely on sys.version format
Lysandros Nikolaou added the comment: I'm working on changing _PY_VERSION to get its value from sys.version_info instead of sys.version, but I am not sure what the best way is to map between a release stage to the corresponding letter(release->rc). Could someone help me a tiny bit with this one? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue24916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24916] In sysconfig, don't rely on sys.version format
Change by Lysandros Nikolaou : -- pull_requests: +9623 ___ Python tracker <https://bugs.python.org/issue24916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21263] test_gdb failures on os x 10.9.2
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +9619 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue21263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22021] shutil.make_archive() root_dir do not work
Change by Lysandros Nikolaou : -- pull_requests: +9668 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue22021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25438] document what codec PyMemberDef T_STRING decodes the char * as
Lysandros Nikolaou added the comment: It's been more than 3 years, since this was opened, but I will ask nevertheless. Should a PR maybe made for this issue? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue25438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17972] inspect module docs omits many functions
Lysandros Nikolaou added the comment: I think this issue should be discussed once more. I am not sure it's worth defining __all__, but then we would have to include them in the docs. If you think __all__ should be defined instead, then I could go through the trouble of doing so. Could a core developer maybe offer their opinion here? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue17972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17972] inspect module docs omits many functions
Lysandros Nikolaou added the comment: ...but then we would have to include them in the docs... should be *but then we would have to include all the public functions in the docs*. -- ___ Python tracker <https://bugs.python.org/issue17972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30533] missing feature in inspect module: getmembers_static
Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue30533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22021] shutil.make_archive() root_dir do not work
Lysandros Nikolaou added the comment: Is anybody working on this or can I submit a PR? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue22021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35251] FTPHandler.ftp_open documentation error
New submission from Lysandros Nikolaou : On https://docs.python.org/3/library/urllib.request.html?highlight=request#ftphandler-objects there is the sentence "The login is always done with empty username and password.", but in the (not so rare) case I am not missing something here, the code does parse the username and password and passes it on to connect_ftp, which then uses them. Should we update the docs? -- components: email messages: 329936 nosy: barry, lys.nikolaou, r.david.murray priority: normal severity: normal status: open title: FTPHandler.ftp_open documentation error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35252] test_functools dead code after FIXME
New submission from Lysandros Nikolaou : In test_functools.TestSingleDispatch.test_invalid_registrations (https://github.com/python/cpython/blob/4c596d54aa6a55e9d2a3db78891e656ebbfb63c8/Lib/test/test_functools.py#L2299) there is a FIXME with an immediate return afterwards that says that the code after the return should only be allowed to run after PEP 560 is implemented. Now that it is implemented the dead code should work fine, so the return has to be deleted. -- components: Tests messages: 329937 nosy: lys.nikolaou priority: normal severity: normal status: open title: test_functools dead code after FIXME versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35252] test_functools dead code after FIXME
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +9797 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35252] test_functools dead code after FIXME
Lysandros Nikolaou added the comment: It actually seems like the test after the FIXME is wrong and should be changed or deleted altogether. Can someone give a pointer or two on what would be the best choice here? -- ___ Python tracker <https://bugs.python.org/issue35252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22021] shutil.make_archive() root_dir do not work
Lysandros Nikolaou added the comment: Since Serhiy said that this is a pure documentation issue, I thought that a doc PR is all that was needed, which I would be happy to make. Am I missing something here? -- ___ Python tracker <https://bugs.python.org/issue22021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24916] In sysconfig, don't rely on sys.version format
Lysandros Nikolaou added the comment: Following up on https://github.com/python/cpython/pull/10321#discussion_r230604393 I would like to summarise here what's been going on, in order to move the discussion here forward. I've tried to make a PR for this issue, in which _PY_VERSION in Lib/sysconfig.py and py_version in Lib/distutils/command/install.py are updated to get their value from sys.version_info instead of sys.version. This PR removes the '+' from both so the issue remains, if we want to keep the '+' info or not. -- ___ Python tracker <https://bugs.python.org/issue24916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34748] Incorrect HTML link in functools.partial
Lysandros Nikolaou added the comment: Can I submit a PR for this or is anybody else on it? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue34748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35398] SQLite incorrect row count for UPDATE
Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue35398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+
Lysandros Nikolaou added the comment: I updated the PR with the new wording by Paul, since I found it easier to understand as well. -- ___ Python tracker <https://bugs.python.org/issue30410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22021] shutil.make_archive() root_dir do not work
Lysandros Nikolaou added the comment: Ping. -- ___ Python tracker <https://bugs.python.org/issue22021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30410] Documentation for sys.stdout encoding does not reflect the new Windows behavior in Python 3.6+
Lysandros Nikolaou added the comment: Ping. -- ___ Python tracker <https://bugs.python.org/issue30410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21314] Document '/' in signatures
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +9891 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue21314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21314] Document '/' in signatures
Change by Lysandros Nikolaou : -- keywords: +patch, patch, patch pull_requests: +9891, 9892, 9893 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue21314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21314] Document '/' in signatures
Change by Lysandros Nikolaou : -- keywords: +patch, patch pull_requests: +9891, 9892 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue21314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35251] FTPHandler.ftp_open documentation error
Lysandros Nikolaou added the comment: Yeah, I am not currently working on this, so feel free to make a PR anytime you want. -- ___ Python tracker <https://bugs.python.org/issue35251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21314] Document '/' in signatures
Lysandros Nikolaou added the comment: Noah, are you working on this? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue21314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35100] urllib.parse.unquote_to_bytes: needs "escape plus" option
Lysandros Nikolaou added the comment: This issue still stands. The output of all three methods is exactly the same as it was when the original question was posted. Would it maybe make sense to add a flag to the unquote_to_bytes method to parse the 'plus' symbol as a space? Or maybe create a new method(i.e. unquote_to_bytes_plus)? -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue35100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21314] Document '/' in signatures
Lysandros Nikolaou added the comment: Ping for review. -- ___ Python tracker <https://bugs.python.org/issue21314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22021] shutil.make_archive() root_dir do not work
Lysandros Nikolaou added the comment: Pinging once more for review. -- ___ Python tracker <https://bugs.python.org/issue22021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36181] Add mode parameter to PurePath.write_text to allow for 'a' mode
Lysandros Nikolaou added the comment: Not that it makes a big difference, but write_text is a method of the Path class, not PurePath. -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue36181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36182] Path.write_text() docs do not include the case that a file exists
Lysandros Nikolaou added the comment: For reference, https://docs.python.org/3/library/pathlib.html#pathlib.Path.write_bytes. -- ___ Python tracker <https://bugs.python.org/issue36182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36182] Path.write_text() docs do not include the case that a file exists
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +12159 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36182] Path.write_text() docs do not include the case that a file exists
Lysandros Nikolaou added the comment: I'll submit a PR shortly. -- ___ Python tracker <https://bugs.python.org/issue36182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36182] Path.write_text() docs do not include the case that a file exists
New submission from Lysandros Nikolaou : Hi, in the pathlib.Path.write_bytes() documentation it is clearly stated that "An existing file of the same name is overwritten." Wouldn't it make sense to include something similar to the pathlib.Path.write_text() docs. I had to quickly test it manually to find out what's happening as it wasn't clear to me if the statement applies to write_text() as well. -- assignee: docs@python components: Documentation messages: 337100 nosy: docs@python, lys.nikolaou priority: normal severity: normal status: open title: Path.write_text() docs do not include the case that a file exists versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36218] .sort() segfaults consistently on crafted input
Lysandros Nikolaou added the comment: Can confirm for 3.7.2 on my macOS 10.14 system. Although this is the case in 3.7 on my current build of the master branch I get the following AssertionError instead: Assertion failed: (v->ob_type == w->ob_type), function unsafe_tuple_compare, file Objects/listobject.c, line 2164 It seems like the AssertionError gets thrown in unsafe_tuple_compare(). Link: https://github.com/python/cpython/blob/dc078947a5033a048d804e244e847b5844734439/Objects/listobject.c#L2164 -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue36218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21314] Document '/' in signatures
Lysandros Nikolaou added the comment: I agree with Nick, that pydoc should somehow be updated to mark positional-only parameters as such. I believe that the third approach proposed by Nick is the most sensible one, as it makes the life of new developers easier by explicitly listing all the positional-only parameters. I could open a new issue and work on a PR, if you all agree that that is the way to go. -- ___ Python tracker <https://bugs.python.org/issue21314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37024] SQLite flag in configure due to homebrew not linking sqlite
Lysandros Nikolaou added the comment: This can be most likely be closed. In the last days I had some unrelated problems with my mac and had to do a full format. After reinstalling macOS the problem went away, so it must have been something specific to my previous state of things that triggered the error. -- ___ Python tracker <https://bugs.python.org/issue37024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37024] SQLite flag in configure due to homebrew not linking sqlite
New submission from Lysandros Nikolaou : Since recently, Homebrew refuses to link sqlite. Upon researching the whole thing, I found out that this is now considered a feature of Homebrew and not a bug. Thus homebrew users on macOS do not get the SQLite module installed by default, because it is not found and have to overwrite CPPFLAGS. Would it make sense to include a --with-sqlite flag, like we do for openssl? -- components: Build messages: 343317 nosy: lys.nikolaou priority: normal severity: normal status: open title: SQLite flag in configure due to homebrew not linking sqlite type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35328] Set a environment variable for venv prompt
Lysandros Nikolaou added the comment: @brettcannon, yeah I saw that, but there hasn't been any progress since November. I'm still interested in this though. What would the correct workflow be? Pushing commits to the same PR or opening a new one with a co-author? -- ___ Python tracker <https://bugs.python.org/issue35328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35328] Set a environment variable for venv prompt
Lysandros Nikolaou added the comment: Is anybody still working on this? -- ___ Python tracker <https://bugs.python.org/issue35328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35328] Set a environment variable for venv prompt
Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue35328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36966] Export __VENV_PROMPT__ as environment variable
Change by Lysandros Nikolaou : -- resolution: -> duplicate ___ Python tracker <https://bugs.python.org/issue36966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36966] Export __VENV_PROMPT__ as environment variable
Lysandros Nikolaou added the comment: It is. Somehow search failed me big time. I'm closing the issue. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36966] Export __VENV_PROMPT__ as environment variable
New submission from Lysandros Nikolaou : For those, who use custom tools for their terminals, prepending __VENV_PROMPT__ to PS1 doesn't really help all that much, because it gets overwritten by those tools. Would it make sense to export __VENV_PROMPT__ as an environment variable upon activation, so that these tools can make use of it, in order to edit PS1 accordingly? -- components: Library (Lib) messages: 342855 nosy: lys.nikolaou priority: normal severity: normal status: open title: Export __VENV_PROMPT__ as environment variable type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35252] test_functools dead code after FIXME
Change by Lysandros Nikolaou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36167] DOC: Incorrect capitalization in Programming FAQ
Lysandros Nikolaou added the comment: Mariatta noted at https://mail.python.org/archives/list/core-mentors...@python.org/message/KFIGNAGJKWQXCXG72VGIGGA3OCKUHOFC/ that these issues are not reserved and are now available for first-time contributors. -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue36167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36168] DOC: Fix capitalization in string.rst
Lysandros Nikolaou added the comment: Mariatta noted at https://mail.python.org/archives/list/core-mentors...@python.org/message/KFIGNAGJKWQXCXG72VGIGGA3OCKUHOFC/ that these issues are not reserved and are now available for first-time contributors. -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue36168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36182] Path.write_text() docs do not include the case that a file exists
Lysandros Nikolaou added the comment: Pinging for review. -- ___ Python tracker <https://bugs.python.org/issue36182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39031] Inconsistency with lineno and col_offset info when parsing elif
Lysandros Nikolaou added the comment: There was a bug in my last PR, hopefully I will get a fix some time later today. The bug is as follows: I only updated the asdl_seq_SET call for an elif without an else, if an else is included then the behavior is like before. After my last PR it looks like this, parsing 2:if a: 3:pass 4:elif b: 5:pass outputs the following AST: Module( body=[ If( test=Name(id="a", ctx=Load(), lineno=2, col_offset=3, end_lineno=2, end_col_offset=4), body=[Pass(lineno=3, col_offset=4, end_lineno=3, end_col_offset=8)], orelse=[ If( test=Name( id="b", ctx=Load(), lineno=4, col_offset=5, end_lineno=4, end_col_offset=6 ), body=[Pass(lineno=5, col_offset=4, end_lineno=5, end_col_offset=8)], orelse=[], lineno=4, col_offset=0, end_lineno=5, end_col_offset=8, ) ], lineno=2, col_offset=0, end_lineno=5, end_col_offset=8, ) ], type_ignores=[], ) On the other hand parsing 2:if a: 3:pass 4:elif b: 5:pass 6:else: 7:pass outputs Module( body=[ If( test=Name( id="a", ctx=Load(), lineno=2, col_offset=3, end_lineno=2, end_col_offset=4, ), body=[Pass(lineno=3, col_offset=4, end_lineno=3, end_col_offset=8)], orelse=[ If( test=Name( id="b", ctx=Load(), lineno=4, col_offset=5, end_lineno=4, end_col_offset=6, ), body=[Pass(lineno=5, col_offset=4, end_lineno=5, end_col_offset=8)], orelse=[ Pass(lineno=7, col_offset=4, end_lineno=7, end_col_offset=8) ], lineno=4, col_offset=5, end_lineno=7, end_col_offset=8, ) ], lineno=2, col_offset=0, end_lineno=7, end_col_offset=8, ) ], type_ignores=[], ) -- ___ Python tracker <https://bugs.python.org/issue39031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39031] Inconsistency with lineno and col_offset info when parsing elif
Change by Lysandros Nikolaou : -- pull_requests: +17068 pull_request: https://github.com/python/cpython/pull/17596 ___ Python tracker <https://bugs.python.org/issue39031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39080] Inconsistency with Starred Expression line/col info
New submission from Lysandros Nikolaou : When a starred expression like *[0, 1] is parsed, the following AST gets generated: Module( body=[ Expr( value=Starred( value=List( elts=[ Constant( value=0, kind=None, lineno=1, col_offset=2, end_lineno=1, end_col_offset=3, ), Constant( value=1, kind=None, lineno=1, col_offset=5, end_lineno=1, end_col_offset=6, ), ], ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=7, ), ctx=Load(), lineno=1, col_offset=0, end_lineno=1, end_col_offset=7, ), lineno=1, col_offset=0, end_lineno=1, end_col_offset=7, ) ], type_ignores=[], ) But, when a starred expression is an argument to a function call then the line/col info are wrong (end_col_offset is always equal to col_offset + 1): Module( body=[ Expr( value=Call( func=Name( id="f", ctx=Load(), lineno=1, col_offset=0, end_lineno=1, end_col_offset=1 ), args=[ Starred( value=List( elts=[ Constant( value=0, kind=None, lineno=1, col_offset=4, end_lineno=1, end_col_offset=5, ), Constant( value=1, kind=None, lineno=1, col_offset=7, end_lineno=1, end_col_offset=8, ), ], ctx=Load(), lineno=1, col_offset=3, end_lineno=1, end_col_offset=9, ), ctx=Load(), lineno=1, col_offset=2, end_lineno=1, end_col_offset=9, ) ], keywords=[], lineno=1, col_offset=0, end_lineno=1, end_col_offset=10, ), lineno=1, col_offset=0, end_lineno=1, end_col_offset=10, ) ], type_ignores=[], ) -- components: Interpreter Core messages: 358584 nosy: lys.nikolaou priority: normal severity: normal status: open title: Inconsistency with Starred Expression line/col info type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39080] Inconsistency with Starred Expression line/col info
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +17113 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17645 ___ Python tracker <https://bugs.python.org/issue39080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39031] Inconsistency with lineno and col_offset info when parsing elif
Change by Lysandros Nikolaou : -- title: Inconsistent lineno and col_offset info when parsing elif -> Inconsistency with lineno and col_offset info when parsing elif ___ Python tracker <https://bugs.python.org/issue39031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39031] Inconsistent lineno and col_offset info when parsing elif
New submission from Lysandros Nikolaou : While working on pegen, we came across an inconsistency on how line number and column offset info is stored for (el)if nodes. When parsing a very simple if-elif construct like if a: pass elif b: pass the following parse tree gets generated: Module( body=[ If( test=Name(id="a", ctx=Load(), lineno=1, col_offset=3, end_lineno=1, end_col_offset=4), body=[Pass(lineno=2, col_offset=4, end_lineno=2, end_col_offset=8)], orelse=[ If( test=Name( id="b", ctx=Load(), lineno=3, col_offset=5, end_lineno=3, end_col_offset=6 ), body=[Pass(lineno=4, col_offset=4, end_lineno=4, end_col_offset=8)], orelse=[], lineno=3, col_offset=5, end_lineno=4, end_col_offset=8, ) ], lineno=1, col_offset=0, end_lineno=4, end_col_offset=8, ) ], type_ignores=[], ) There is the inconsistency that the column offset for the if statement is 0, thus the if statement starts with the keyword if, whereas the column offset for elif if 5, which means that the elif keyword is skipped. As Guido suggests over at https://github.com/gvanrossum/pegen/issues/107#issuecomment-565135047 we could very easily change Python/ast.c so that the elif statement start with the elif keyword as well. I have a PR ready! -- messages: 358304 nosy: lys.nikolaou priority: normal severity: normal status: open title: Inconsistent lineno and col_offset info when parsing elif type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39031] Inconsistency with lineno and col_offset info when parsing elif
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +17056 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17582 ___ Python tracker <https://bugs.python.org/issue39031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39031] Inconsistency with lineno and col_offset info when parsing elif
Change by Lysandros Nikolaou : -- pull_requests: +17059 pull_request: https://github.com/python/cpython/pull/17585 ___ Python tracker <https://bugs.python.org/issue39031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39474] col_offset for parenthesized expressions looks weird
Lysandros Nikolaou added the comment: Are you going to work on a patch then, Batuhan? -- ___ Python tracker <https://bugs.python.org/issue39474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39474] col_offset for parenthesized expressions looks weird
Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue39474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39564] Parsed expression has wrong col_offset when concatenating f-strings
Change by Lysandros Nikolaou : -- title: Parsed expression has wrong line/col info when concatenating f-strings -> Parsed expression has wrong col_offset when concatenating f-strings ___ Python tracker <https://bugs.python.org/issue39564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39564] Parsed expression has wrong line/col info when concatenating f-strings
New submission from Lysandros Nikolaou :
When concatenating f-strings, if there is an expression in any STRING node
other than the first, col_offset of the parsed expression has a wrong value.
For example, parsing f"hello" f"{world}" outputs the following AST:
Module(
body=[
Expr(
value=JoinedStr(
values=[
Constant(
value="hello",
kind=None,
lineno=1,
col_offset=0,
end_lineno=1,
end_col_offset=19,
),
FormattedValue(
value=Name(
id="world",
ctx=Load(),
lineno=1,
*col_offset=1,*
end_lineno=1,
*end_col_offset=6,*
),
conversion=-1,
format_spec=None,
lineno=1,
col_offset=0,
end_lineno=1,
end_col_offset=19,
),
],
lineno=1,
col_offset=0,
end_lineno=1,
end_col_offset=19,
),
lineno=1,
col_offset=0,
end_lineno=1,
end_col_offset=19,
)
],
type_ignores=[],
)
Here, col_offset and end_col_offset are wrong in the parsed NAME 'world'.
--
components: Interpreter Core
messages: 361456
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parsed expression has wrong line/col info when concatenating f-strings
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39564>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39564] Parsed expression has wrong col_offset when concatenating f-strings
Lysandros Nikolaou added the comment: Also note that for pegen this is a solved problem. If we decide to change the parser, it may not be worth it to spend too much time on a universal solution. -- ___ Python tracker <https://bugs.python.org/issue39564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39564] Parsed expression has wrong col_offset when concatenating f-strings
Lysandros Nikolaou added the comment: > Can I ask how pegen solved this problem? Did you move parsing of f-strings > into the grammar? No, we actually do a very similar thing to what ast.c does. I think there is only one major difference between what pegen does and what ast.c does. If I understand correctly, fstring_compile_expr calls fstring_fix_node_location with parent set to the whole STRING+ node. We OTOH only pass as parent the current STRING token (we work with tokens returned by the tokenizer) and then walk the AST tree and adjust the line/col_offset based on that. I'm not sure that this is bug-free, but after some testing, I could find any obvious errors. If you want, you can take a loot at the code on https://github.com/gvanrossum/pegen/pull/183. -- ___ Python tracker <https://bugs.python.org/issue39564> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39579] Attribute node in a decorator has wrong end_col_offset
New submission from Lysandros Nikolaou : There is a problem with the end_col_offset of nested Attribute nodes in decorators. For example, parsing @a.b.c def f(): pass produces the following AST tree (part): decorator_list=[ Attribute( value=Attribute( value=Name( id="a", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=2, ), attr="b", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, *end_col_offset=6*, ), attr="c", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=6, ) ], Note that the Attribute node with attr="b" has end_col_offset=6, while it should actually be 4. -- components: Interpreter Core messages: 361595 nosy: gvanrossum, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Attribute node in a decorator has wrong end_col_offset versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39579] Attribute node in a decorator has wrong end_col_offset
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +17781 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18405 ___ Python tracker <https://bugs.python.org/issue39579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39579] Attribute node in a decorator has wrong end_col_offset
Change by Lysandros Nikolaou : -- pull_requests: +17783 pull_request: https://github.com/python/cpython/pull/18408 ___ Python tracker <https://bugs.python.org/issue39579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39633] venv does not include python. symlink by default
New submission from Lysandros Nikolaou : At the moment running python -m venv venv or python3 -m venv venv creates a virtual environment that does not contain a python. symlink, which results in executing whatever the default python is when running i.e. python. within an activated virtual env. OTOH if one runs python. -m venv venv, then everything is OK. Would it be possible to include a python. symlink in all cases? If not, then I think we should update the docs to mention that somewhere, since it took me quite a while to figure this out. -- components: Library (Lib) messages: 361993 nosy: lys.nikolaou priority: normal severity: normal status: open title: venv does not include python. symlink by default versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39633] venv does not include python. symlink by default
Lysandros Nikolaou added the comment: The thing is that some projects I've worked on, like pegen, include a Makefile which uses `pythonX.Y` to choose the version and I have to change it to `python` quite frequently. I can't really figure out any way this could harm anyone, other than what you said (running `pythonX.Y` with the wrong values for X and Y), but even in that case you get something like `command not fonund` and that's an easy enough typo to find. -- ___ Python tracker <https://bugs.python.org/issue39633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39633] venv does not include python. symlink by default
Lysandros Nikolaou added the comment: You're right! That could be very confusing. But isn't this risk already there, since this could happen if one runs `python3.8 -m venv venv` and then `python3.7` with the venv activated? -- ___ Python tracker <https://bugs.python.org/issue39633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39633] venv does not include python. symlink by default
Lysandros Nikolaou added the comment: That's right. I'll do that then. Thanks for baring with me. Should we update the docs to mentiom this or just close this issue? On Sat, Feb 15, 2020, 22:33 Vinay Sajip wrote: > > Vinay Sajip added the comment: > > In general, people should be working in venvs. That means that libraries > should assume they are being installed into venvs. Therefore makefiles > should be invoking plain "python" rather than "pythonX.Y", as they can > never be sure which exact interpreter they're running under (you might have > a newer one than the one in the Makefile - that shouldn't fail). Why not > raise this as an issue with these projects? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39633> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16806] col_offset is -1 and lineno is wrong for multiline string expressions
Change by Lysandros Nikolaou : -- pull_requests: +17320 pull_request: https://github.com/python/cpython/pull/17582 ___ Python tracker <https://bugs.python.org/issue16806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39235] Generator expression has wrong line/col info when inside a Call object
New submission from Lysandros Nikolaou : A normal generator expression like (i for i in a) produces the following AST: Module( body=[ Expr( value=GeneratorExp( elt=Name( id="i", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=2 ), generators=[ comprehension( target=Name( id="i", ctx=Store(), lineno=1, col_offset=7, end_lineno=1, end_col_offset=8, ), iter=Name( id="a", ctx=Load(), lineno=1, col_offset=12, end_lineno=1, end_col_offset=13, ), ifs=[], is_async=0, ) ], lineno=1, *col_offset=0,* end_lineno=1, *end_col_offset=14,* ), lineno=1, col_offset=0, end_lineno=1, end_col_offset=14, ) ], type_ignores=[], ) But when calling a function with a generator expression as an argument, something is off: Module( body=[ Expr( value=Call( func=Name( id="f", ctx=Load(), lineno=1, col_offset=0, end_lineno=1, end_col_offset=1 ), args=[ GeneratorExp( elt=Name( id="i", ctx=Load(), lineno=1, col_offset=2, end_lineno=1, end_col_offset=3, ), generators=[ comprehension( target=Name( id="i", ctx=Store(), lineno=1, col_offset=8, end_lineno=1, end_col_offset=9, ), iter=Name( id="a", ctx=Load(), lineno=1, col_offset=13, end_lineno=1, end_col_offset=14, ), ifs=[], is_async=0, ) ], lineno=1, *col_offset=1,* end_lineno=1, *end_col_offset=2,* ) ], keywords=[], lineno=1, col_offset=0, end_lineno=1, end_col_offset=15, ), lineno=1, col_offset=0, end_lineno=1, end_col_offset=15, ) ], type_ignores=[], ) I'm not sure if this is intentional or not, because there is a call to copy_location in Python/ast.c:3149. If this call to copy_location is removed, the inconsistency goes away. -- components: Interpreter Core messages: 359454 nosy: lys.nikolaou priority: normal severity: normal status: open title: Generator expression has wrong line/col info when inside a Call object type: behavior versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39235] Generator expression has wrong line/col info when inside a Call object
Lysandros Nikolaou added the comment: Do you think it is okay to just remove the call to copy_location? -- ___ Python tracker <https://bugs.python.org/issue39235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40267] Error message differs when an expression is in an fstring
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +18871 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19521 ___ Python tracker <https://bugs.python.org/issue40267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Lysandros Nikolaou added the comment: In my understanding of the C code that's what the C tokenizer is doing as well. Here's the relevant snippet of the tokenizer (https://github.com/python/cpython/blob/4b222c9491d1700e9bdd98e6889b8d0ea1c7321e/Parser/tokenizer.c#L1358): When the tokenizer sees a valid identifier start, it goes into a loop that checks for a valid combination of string prefixes. If the combination is valid and it sees a quote directly after that, it goto's to the STRING-handling code. If not, then it breaks out of the loop and returns a NAME node. Am I missing something? -- ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Lysandros Nikolaou added the comment: I have working code that checks if there is a quotation mark right after an identifier. Here is an example: ╰─ ./python Python 3.9.0a5+ (heads/pegen-dirty:502dfb719e, Apr 11 2020, 14:43:12) [GCC 9.2.1 20191008] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ur'' File "", line 1 ur'' ^ SyntaxError: invalid string prefix One observation about this is that it has precedence over an EOL error: >>> ur' File "", line 1 ur' ^ SyntaxError: invalid string prefix Would that be acceptable? -- ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Change by Lysandros Nikolaou : -- keywords: +patch pull_requests: +18830 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19476 ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40334] PEP 617: new PEG-based parser
Change by Lysandros Nikolaou : -- nosy: +lys.nikolaou ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
New submission from Lysandros Nikolaou :
While testing pegen, we found this out:
Python 3.9.0a5+ (heads/pegen:502dfb719e, Apr 10 2020, 20:57:05)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> fur''
File "", line 1
fur''
^
SyntaxError: invalid syntax
>>> eval("fur''")
Traceback (most recent call last):
File "", line 1, in
File "", line 1
fur''
^
SyntaxError: unexpected EOF while parsing
--
components: Interpreter Core
messages: 366143
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: Different error messages for same error - invalid string prefixes
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40246>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Change by Lysandros Nikolaou : -- nosy: +gvanrossum, pablogsal ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40267] Error message differs when an expression is in an fstring
Lysandros Nikolaou added the comment:
It seems that this is actually a bit bigger than this and it is not specific to
f-strings.
The error message *always* changes to `unexpected EOF while parsing` if there
is an error with the last character of the input and no newline follows. For
example, as made clear to me by Guido, there are even differences in error
messages between exec'ing and eval'ing something:
>>> exec('x+')
Traceback (most recent call last):
File "", line 1, in
File "", line 1
x+
^
SyntaxError: invalid syntax
>>> eval('x+')
Traceback (most recent call last):
File "", line 1, in
File "", line 1
x+
^
SyntaxError: unexpected EOF while parsing
That's because the tokenizer adds an implicit newline to the input string,
before tokenizing it, when the input comes from an exec call. (see
https://github.com/python/cpython/blob/14d5331eb5e6c38be12bad421bd59ad0fac9e448/Parser/tokenizer.c#L648)
And that's not limited to a character missing, as suggested by the error
message. Even when the last character itself generates a SyntaxError, the error
message remains "unexpcted EOF while parsing":
>>> x+@
File "", line 1
x+@
^
SyntaxError: invalid syntax
>>> eval('x+@')
Traceback (most recent call last):
File "", line 1, in
File "", line 1
x+@
^
SyntaxError: unexpected EOF while parsing
Thus, a very simple fix to the specific fstring problem of this issue would be
to add a newline to the string that gets parsed to the parser in
fstring_compile_expr in ast.c, but I guess it'd be better to fix the tokenizer
itself, if this is considered a bug.
--
___
Python tracker
<https://bugs.python.org/issue40267>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40267] Error message differs when an expression is in an fstring
New submission from Lysandros Nikolaou :
There are cases, where the error message differs, when an expression is being
parsed inside an fstring. For example:
>>> f'{x+}'
File "", line 1
(x+)
^
SyntaxError: unexpected EOF while parsing
>>> (x+)
File "", line 1
(x+)
^
SyntaxError: invalid syntax
Or with lambda definitions:
>>> f'{lambda x:x}'
File "", line 1
(lambda x)
^
SyntaxError: unexpected EOF while parsing
>>> (lambda x)
File "", line 1
(lambda x)
^
SyntaxError: invalid syntax
--
components: Interpreter Core
messages: 366272
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Error message differs when an expression is in an fstring
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40267>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Lysandros Nikolaou added the comment: After some investigating, I found out that this is happening because when we execute `fur''` in the interactive interpreter there is an implicit newline, which means that EOF does not get reached. OTOH there is no newline when passing it as a string inside an `eval` call. After the tokenizer encounters the first quote, it calls `tok_nextc` twice more, in order to differentiate between a single-quoted and a triple-quoted string, thus reaching EOF and proapgating an EOF error up through the `perrdetail` struct. -- ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40267] Error message differs when an expression is in an fstring
Change by Lysandros Nikolaou : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue40267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Lysandros Nikolaou added the comment: At the moment, if the prefix is invalid, it gets tokenized as a NAME node and the string following is tokenized as a STRING node with no prefix. ╰─ echo "ur''" | ./python -m tokenize 1,0-1,2:NAME 'ur' 1,2-1,4:STRING "''" 1,4-1,5:NEWLINE'\n' 2,0-2,0:ENDMARKER '' ╰─ echo "f''" | ./python -m tokenize 1,0-1,3:STRING "f''" 1,3-1,4:NEWLINE'\n' 2,0-2,0:ENDMARKER '' -- ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40334] PEP 617: new PEG-based parser
Change by Lysandros Nikolaou : -- pull_requests: +19091 pull_request: https://github.com/python/cpython/pull/19771 ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40334] PEP 617: new PEG-based parser
Change by Lysandros Nikolaou : -- pull_requests: +19094 pull_request: https://github.com/python/cpython/pull/19774 ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
