[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
I missed the discussion around the PEP. I don't mean to start another one, I'd just like a clarification. The PEP describes the new functionality, and the interfaces, and that's all fine. But I didn't see where it discussed where this technology would be used. Would this mainly be used by third-party math libraries (Pandas, NumPy), like the @ operator, or is there a plan to use this in Python's own library or builtin objects? If the latter, can you go into the specifics? I'm guessing the typing module would use it, as illustrated by one of the examples, but beyond that I can't imagine how this would be used by e.g. dicts and lists. Thanks, //arry/ On 2/2/21 3:36 AM, Stefano Borini wrote: Hi all, I would like to request feedback by python-dev on the current implementation of PEP 637 - Support for indexing with keyword arguments. https://www.python.org/dev/peps/pep-0637/ The PEP is ready for SC submission and it has a prototype implementation ready, available here (note, not reviewed, but apparently fully functional) https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2 (note: not sure if there's a preference for the link to be to the diff or to the branch, let me know if you prefer I change the PEP link) Thank you for your help. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TMAEJYBI7N73L64JPFODOGYD6KQY5PIH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-01-29 - 2021-02-05) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7379 (-209) closed 47495 (+284) total 54874 (+75) Open issues with patches: 2926 Issues opened (55) == #16202: sys.path[0] security issues https://bugs.python.org/issue16202 reopened by christian.heimes #24275: lookdict_* give up too soon https://bugs.python.org/issue24275 reopened by Jim.Jewett #42278: Remove usage of tempfile.mktemp in stdlib https://bugs.python.org/issue42278 reopened by epaine #42616: C Extensions on Darwin that link against libpython are likely https://bugs.python.org/issue42616 reopened by froody #43048: Printing RecursionError results in RecursionError https://bugs.python.org/issue43048 reopened by iritkatriel #43064: Cannot clear signal handler set with loop.add_signal_handler i https://bugs.python.org/issue43064 opened by selimb #43065: 'concurrent.futures' stucks in 3.9.1 https://bugs.python.org/issue43065 opened by doublex #43066: Zipfile with leading slashes https://bugs.python.org/issue43066 opened by garrison.taylor #43067: inspect.signature(bytes.hex) raises ValueError "builtin has in https://bugs.python.org/issue43067 opened by boris #43068: test_subprocess: test_specific_shell() fails on AMD64 FreeBSD https://bugs.python.org/issue43068 opened by vstinner #43069: Python fails to read a script whose path is `/dev/fd/X` https://bugs.python.org/issue43069 opened by ciprian.craciun #43071: IDLE: Windows 7 - Trackpad two-finger vertical scrolling is no https://bugs.python.org/issue43071 opened by Kritzy #43072: Memory Leak when using Thread https://bugs.python.org/issue43072 opened by goyalakshat14 #43073: Adding a ctypes.Union to a ctypes.BigEndianStructure results i https://bugs.python.org/issue43073 opened by MrSurly #43075: ReDoS in request https://bugs.python.org/issue43075 opened by yetingli #43077: Update bundled pip to 21.0.1 and setuptools to 52.0.0 https://bugs.python.org/issue43077 opened by paul.moore #43079: wrong IP address range given for ipv4_mapped https://bugs.python.org/issue43079 opened by alwhaley #43080: pprint for dataclass instances https://bugs.python.org/issue43080 opened by LewisGaul #43081: Recursive call crash module multiprocessing https://bugs.python.org/issue43081 opened by xxm #43084: curses.window.enclose() should return bool https://bugs.python.org/issue43084 opened by serhiy.storchaka #43085: Loosening | and |= operator type checking restriction https://bugs.python.org/issue43085 opened by Siy_V #43086: Excess data in not handled properly in binascii.a2b_base64() https://bugs.python.org/issue43086 opened by idan22moral #43087: ctypes documentation error https://bugs.python.org/issue43087 opened by metolone #43092: Python installation fails to install pip3 if pip, setuptools i https://bugs.python.org/issue43092 opened by quotemstr #43093: Make modules picklable https://bugs.python.org/issue43093 opened by Arusekk #43094: sqlite3.create_function takes parameter named narg, not num_pa https://bugs.python.org/issue43094 opened by nchammas #43095: Windows does not raise IsADirectoryError https://bugs.python.org/issue43095 opened by Jairo Llopis #43096: Adding `read_into` method to `asyncio.StreamReader` https://bugs.python.org/issue43096 opened by jakirkham #43098: tarfile list() method does not show file type https://bugs.python.org/issue43098 opened by val.shkolnikov #43101: Add deprecation of float limits for resource to documentation https://bugs.python.org/issue43101 opened by nafur #43103: Add configure --without-static-libpython to not build libpytho https://bugs.python.org/issue43103 opened by vstinner #43105: Can't import extension modules resolved via relative paths in https://bugs.python.org/issue43105 opened by smunday #43109: When using Apple Clang, --with-lto builds should not check for https://bugs.python.org/issue43109 opened by acmorrow #43111: webbrowser.py triggers unwanted XQuartz startup https://bugs.python.org/issue43111 opened by hans-meine #43112: SOABI on Linux does not distinguish between GNU libc and musl https://bugs.python.org/issue43112 opened by ncopa #43115: locale.getlocale fails if locale is set https://bugs.python.org/issue43115 opened by AndersMunch #43118: inspect.signature() raises RuntimeError on failed to resolve t https://bugs.python.org/issue43118 opened by tkomiya #43119: asyncio.Queue.put never yields if the queue is unbounded https://bugs.python.org/issue43119 opened by spenczar #43120: Some OSX syslog facilities are missing from syslog module https://bugs.python.org/issue43120 opened by ronaldoussoren #43122: Python Launcher doesn't open a terminal window https://bugs.python.org/issue43122 opened by kjw #43123: email MIME splitting https://bugs.python.org/issue43123 o
[Python-Dev] Re: What's up with assignment expression and tuples?
On 2/5/2021 2:51 AM, Paul Sokolovsky wrote: https://www.python.org/dev/peps/pep-0572/ ... ((a, b) := (1, 2)) File "", line 1 SyntaxError: cannot use assignment expressions with tuple Why this accidental syntactic gap? As should be clear from reading "Differences between assignment expressions and assignment statements", this 'gap' in entirely intentional, not accidental. *All* elaborations of 'name := expression' are listed and rejected as outside the scope of the proposal, which was to keep one reference to the expression value for later use. At least some of these elaborations were suggested and rejected during the voluminous discussion. The principal a.e. use in conditional expressions is testing for non-nullness. Your > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: >a2 = a1 + 1 >b2 = b1 + 1 is an unusual and very specific use. You want to have your tuple (for subscripting for testing) and eat it too (by unpacking). One can instead separate unpacking from testing a couple of ways while (tup := phi([a0, a2], [b0, b2]))[0] < 5: a2, b2 = tup a2 = a1 + 1 b2 = b1 + 1 while True: a1, b1 = phi([a0, a2], [b0, b2]) if a1 >= 5: break a2 = a1 + 1 b2 = b1 + 1 -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VM3OJ4E73DQXHNUB2JV67JALI2EEO3DP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: What's up with assignment expression and tuples?
Hello, Thanks for the reply. On Fri, 5 Feb 2021 13:32:25 -0500 Terry Reedy wrote: > On 2/5/2021 2:51 AM, Paul Sokolovsky wrote: > > > https://www.python.org/dev/peps/pep-0572/ > ... > > ((a, b) := (1, 2)) > >File "", line 1 > > SyntaxError: cannot use assignment expressions with tuple > > > > > > Why this accidental syntactic gap? > > As should be clear from reading "Differences between assignment > expressions and assignment statements", this 'gap' in entirely > intentional, not accidental. *All* elaborations of 'name := > expression' are listed and rejected as outside the scope of the > proposal, which was to keep one reference to the expression value for > later use. At least some of these elaborations were suggested and > rejected during the voluminous discussion. And looking back now, that seems like intentionally added accidental gap in the language (https://en.wikipedia.org/wiki/Accidental_gap). Similar to artificially limiting decorator syntax, which was already un-limited. But seems, there're no "lessons learned", and there's now need to wait a decade again before fixing that? > The principal a.e. use in conditional expressions is testing for > non-nullness. Your > > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > >a2 = a1 + 1 > >b2 = b1 + 1 > > is an unusual and very specific use. Well, many people were thinking (and I bet still think) that ":=" itself is very unusual case. But if it's in, why not make it consistent with the assignment statement and unleash the full power of it? > You want to have your tuple > (for subscripting for testing) and eat it too (by unpacking). That's good characterization, thanks. And Python syntax alone would allow to do that, if not extra-syntactical limitations put on top of it. > One can instead separate unpacking from testing a couple of ways > > while (tup := phi([a0, a2], [b0, b2]))[0] < 5: > a2, b2 = tup > a2 = a1 + 1 > b2 = b1 + 1 > > > while True: > a1, b1 = phi([a0, a2], [b0, b2]) > if a1 >= 5: break > a2 = a1 + 1 > b2 = b1 + 1 Right, but I started my original email with "I finally found a usecase where *not* using assignment expression is *much* worse than using it." Both conversions above apply additional disturbances to the original program, beyond pure SSA conversion, which is quite a disturbance on its own. I was really excited that Python 3.7+ would be *the* language which would allow to express SSA conversion faithfully on the source form of the high-level language (usually SSA is applied to low-level assembly-like intermediate representation). But oops, accidental gap, and despite all the Python advanceness, still need to apply workarounds as with other mundane languages. [] -- Best regards, Paul mailto:pmis...@gmail.com ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/X3LNCCO6PHTLAQXHEAP6T3FFW5ZW5GR5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: What's up with assignment expression and tuples?
On 5/02/21 8:51 pm, Paul Sokolovsky wrote: a = 0 while a < 5: a += 1 becomes: a0 = 0 while (a1 := phi(a0, a2)) < 5: a2 = a1 + 1 SSA seems to be something intended for compilers to use as an intermediate representation, not something to actually write code in. So I'm puzzled as to why you would want to do this. Also, what definition do you have in mind for phi? It doesn't seem to be something you can implement as a real function. -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UBXNDF4QL7I2IWQSUTIPCNLZXGOCG23D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission
dicts and lists will keep working as before. They will not support keyword arguments (probably ever, as there is no clear semantic for them) and the current implementation simply throws an error if the user tries to. Other classes will take advantage of the syntax for enhanced behavior. We are not specifying what that specific behavior might be (as in the case of the @ operator, which is "kind of bound" to a matmul operation, although it can be used for anything else, like / is used as a join operator in pathlib, even though its typical meaning is a division operator). Any class that is willing to accept keyword arguments for the indexing operation is responsible for documenting which arguments are accepted and what is the meaning of their use. We do not prescribe any rule, although some uses can probably be classified as bad practice. On Fri, 5 Feb 2021 at 10:30, Larry Hastings wrote: > > > I missed the discussion around the PEP. I don't mean to start another one, > I'd just like a clarification. The PEP describes the new functionality, and > the interfaces, and that's all fine. But I didn't see where it discussed > where this technology would be used. > > Would this mainly be used by third-party math libraries (Pandas, NumPy), like > the @ operator, or is there a plan to use this in Python's own library or > builtin objects? If the latter, can you go into the specifics? I'm guessing > the typing module would use it, as illustrated by one of the examples, but > beyond that I can't imagine how this would be used by e.g. dicts and lists. > > > Thanks, > > > /arry > > On 2/2/21 3:36 AM, Stefano Borini wrote: > > Hi all, > > I would like to request feedback by python-dev on the current > implementation of PEP 637 - Support for indexing with keyword > arguments. > > https://www.python.org/dev/peps/pep-0637/ > > The PEP is ready for SC submission and it has a prototype > implementation ready, available here (note, not reviewed, but > apparently fully functional) > > https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2 > > (note: not sure if there's a preference for the link to be to the diff > or to the branch, let me know if you prefer I change the PEP link) > > Thank you for your help. > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/TMAEJYBI7N73L64JPFODOGYD6KQY5PIH/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LMAYSMML5QEEWROPEL52I43GB2DPWJMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
