Python-ideas September 2019

python-ideas@python.org

76 participants
48 discussions

Re: Python-ideas Digest, Vol 154, Issue 27

by Brian O'Neill

Oh gosh, that's great but it's great++ with the dream-within-a-dream frame :D :* On Sep 8, 2019, at 12:29 PM, python-ideas-request(a)python.org wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > Today's Topics: > > 1. Re: Automatic translation of Python to assembly language > (Mark @pysoniq) > 2. Re: Automatic translation of Python to assembly language > (Antoine Pitrou) > 3. Re: Automatic translation of Python to assembly language > (Chris Angelico) > 4. Re: Automatic translation of Python to assembly language > (David Mertz) > 5. Re: Automatic translation of Python to assembly language > (David Mertz) > > > ---------------------------------------------------------------------- > > Date: Sun, 08 Sep 2019 16:00:11 -0000 > From: "Mark @pysoniq" <mark(a)pysoniq.com> > Subject: [Python-ideas] Re: Automatic translation of Python to > assembly language > To: python-ideas(a)python.org > Message-ID: <156795841188.4866.611255073798041054(a)mail.python.org> > Content-Type: text/plain; charset="utf-8" > > I forgot to mention that I received private feedback that was useful with respect to the technical discussion: > > The core technologies used are discussed in detail in the first five blog entries -- that is the heart of the project. > > Mark > > ------------------------------ > > Date: Sun, 8 Sep 2019 18:01:44 +0200 > From: Antoine Pitrou <solipsis(a)pitrou.net> > Subject: [Python-ideas] Re: Automatic translation of Python to > assembly language > To: python-ideas(a)python.org > Message-ID: <20190908180144.3b07595f@fsol> > Content-Type: text/plain; charset=UTF-8 > > > How is your approach different from, say, Cython, Nuitka or Pythran? > > Regards > > Antoine. > > > On Sun, 08 Sep 2019 15:56:04 -0000 > "Mark @pysoniq" <mark(a)pysoniq.com> wrote: >> Hi, Anders, >> >> The availability of a free extension every 30 days is a big benefit to the Python community that may not be immediately obvious. That’s not your standard freemium, as it has all the “features” of the paid product -- full registers, multicore, SIMD and other optimizations – so when we say it’s $600 per year of advanced software, that’s true. Our view is that the free extension every 30 days can make a huge difference to a developer with funding limitations (like us). If that free extension makes their project much more successful, then the entire Python community benefits. >> >> We considered this as an open source project, but we haven’t done that for two reasons: >> >> We have looked for and not found a large enough community of volunteers who have the skills to translate Python directly to assembly language without intermediate representation, and optimize the instructions, to make it open source. >> >> Open source projects are often very underfunded and don’t have enough volunteers even from a larger pool of possible people. For example, at PyCon 2019 Victor Stinner eloquently discussed the funding problems at python.org – a shrinking volunteer base and growing issues list. >> >> If I am wrong and there is a large enough group with the requisite skills, then of course we’re very open to the idea of open source, but the technologies used are very leading edge. And again, if you view it with nuance, the $600 a year (12 extensions) could make a huge difference to an under-funded project, of which there are many! >> >> Mark >> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VTIZH… >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > ------------------------------ > > Date: Mon, 9 Sep 2019 02:07:12 +1000 > From: Chris Angelico <rosuav(a)gmail.com> > Subject: [Python-ideas] Re: Automatic translation of Python to > assembly language > To: python-ideas <python-ideas(a)python.org> > Message-ID: > <CAPTjJmrEBT26k4Zz=bOyhMpTYoE9wgdOzzS=_z90HJYyqxrJ7g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Sun, Sep 8, 2019 at 10:47 PM Mark @pysoniq <mark(a)pysoniq.com> wrote: >> >> Hello to the list, >> >> I have an idea for Python that is non-traditional in that it doesn’t extend or modify existing Python language structure. >> >> The idea uses Python to translate Python, entirely under program control, directly to optimized assembly language .dll or .so files, called “extensions.” >> >> Extensions are called from Python using Python’s ctypes interface. The ctypes wrapper for each extension is created automatically. >> >> The goal of this idea is for Python to perform as fast or faster than C or C++, without leaving Python. > > Can you clarify here please: What exactly is the idea you're > proposing? That CPython make use of your project for its own > acceleration? That something be done in the language and/or > interpreter to make your project more effective? > > If your project does already exist, there doesn't seem to be a > proposal here - or else I'm just misreading this. > > ChrisA > > ------------------------------ > > Date: Sun, 8 Sep 2019 12:14:58 -0400 > From: David Mertz <mertz(a)gnosis.cx> > Subject: [Python-ideas] Re: Automatic translation of Python to > assembly language > To: Chris Angelico <rosuav(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Message-ID: > <CAEbHw4ZpQPEimNYK0iKdGuC+_VHbT9t8Nmm+9QwAOkYvf+q-kw(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="000000000000c07b0305920cf9b5" > > --000000000000c07b0305920cf9b5 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > I think the "proposal" is "people should give us money." :-) > > Yes, ads for commercial software do not belong on this list. > > On Sun, Sep 8, 2019, 12:08 PM Chris Angelico <rosuav(a)gmail.com> wrote: > >> On Sun, Sep 8, 2019 at 10:47 PM Mark @pysoniq <mark(a)pysoniq.com> wrote: >>> >>> Hello to the list, >>> >>> I have an idea for Python that is non-traditional in that it doesn=E2= > =80=99t >> extend or modify existing Python language structure. >>> >>> The idea uses Python to translate Python, entirely under program >> control, directly to optimized assembly language .dll or .so files, call= > ed >> =E2=80=9Cextensions.=E2=80=9D >>> >>> Extensions are called from Python using Python=E2=80=99s ctypes interfa= > ce. The >> ctypes wrapper for each extension is created automatically. >>> >>> The goal of this idea is for Python to perform as fast or faster than C >> or C++, without leaving Python. >> >> Can you clarify here please: What exactly is the idea you're >> proposing? That CPython make use of your project for its own >> acceleration? That something be done in the language and/or >> interpreter to make your project more effective? >> >> If your project does already exist, there doesn't seem to be a >> proposal here - or else I'm just misreading this. >> >> ChrisA >> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/JFM= > ZEOQIUZMGW23VFID3PKMQ4RCP2BTR/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > --000000000000c07b0305920cf9b5 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"auto">I think the "proposal" is "people should g= > ive us money." :-)<div dir=3D"auto"><br></div><div dir=3D"auto">Yes, a= > ds for commercial software do not belong on this list.</div></div><br><div = > class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep 8, = > 2019, 12:08 PM Chris Angelico <<a href=3D"mailto:rosuav@gmail.com">rosua= > v(a)gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= > =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, = > Sep 8, 2019 at 10:47 PM Mark @pysoniq <<a href=3D"mailto:mark@pysoniq.co= > m" target=3D"_blank" rel=3D"noreferrer">mark(a)pysoniq.com</a>> wrote:<br> > ><br> > > Hello to the list,<br> > ><br> > > I have an idea for Python that is non-traditional in that it doesn=E2= > =80=99t extend or modify existing Python language structure.<br> > ><br> > > The idea uses Python to translate Python, entirely under program contr= > ol,=C2=A0 directly to optimized assembly language .dll or .so files, called= > =E2=80=9Cextensions.=E2=80=9D<br> > ><br> > > Extensions are called from Python using Python=E2=80=99s ctypes interf= > ace.=C2=A0 The ctypes wrapper for each extension is created automatically.<= > br> > ><br> > > The goal of this idea is for Python to perform as fast or faster than = > C or C++, without leaving Python.<br> > <br> > Can you clarify here please: What exactly is the idea you're<br> > proposing? That CPython make use of your project for its own<br> > acceleration? That something be done in the language and/or<br> > interpreter to make your project more effective?<br> > <br> > If your project does already exist, there doesn't seem to be a<br> > proposal here - or else I'm=C2=A0 just misreading this.<br> > <br> > ChrisA<br> > _______________________________________________<br> > Python-ideas mailing list -- <a href=3D"mailto:python-ideas@python.org" tar= > get=3D"_blank" rel=3D"noreferrer">python-ideas(a)python.org</a><br> > To unsubscribe send an email to <a href=3D"mailto:python-ideas-leave@python= > .org" target=3D"_blank" rel=3D"noreferrer">python-ideas-leave(a)python.org</a= >> <br> > <a href=3D"https://mail.python.org/mailman3/lists/python-ideas.python.org/"= > rel=3D"noreferrer noreferrer" target=3D"_blank">https://mail.python.org/ma= > ilman3/lists/python-ideas.python.org/</a><br> > Message archived at <a href=3D"https://mail.python.org/archives/list/python= > -ideas(a)python.org/message/JFMZEOQIUZMGW23VFID3PKMQ4RCP2BTR/" rel=3D"norefer= > rer noreferrer" target=3D"_blank">https://mail.python.org/archives/list/pyt= > hon-ideas(a)python.org/message/JFMZEOQIUZMGW23VFID3PKMQ4RCP2BTR/</a><br> > Code of Conduct: <a href=3D"http://python.org/psf/codeofconduct/" rel=3D"no= > referrer noreferrer" target=3D"_blank">http://python.org/psf/codeofconduct/= > </a><br> > </blockquote></div> > > --000000000000c07b0305920cf9b5-- > > ------------------------------ > > Date: Sun, 8 Sep 2019 12:28:45 -0400 > From: David Mertz <mertz(a)gnosis.cx> > Subject: [Python-ideas] Re: Automatic translation of Python to > assembly language > To: Antoine Pitrou <solipsis(a)pitrou.net> > Cc: python-ideas <python-ideas(a)python.org> > Message-ID: > <CAEbHw4Y2QBHcENEKfbv-gAW+hWjpUbtZNEnOOxxkwzD47xX1vw(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="00000000000007eea505920d2ba1" > > --00000000000007eea505920d2ba1 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Also PyPy and Numba. > > Cython actually seems a bit different. Without annotations in a superset > language, Cython programs mostly just use the same CPython runtime > libraries. However, with a few type annotations sprinkled in (but not > actual Python syntax), it can get big speedups). > > PyPy actually tried to do direct-to-machine-code for a while. But my > understanding is that they decided=E2=80=94as did Numba=E2=80=94that buildi= > ng on top of the > work of LLVM was more effective (and more cross-architecture). > > Obviously, the ad for a commercial product leaves a bad taste in my mouth. > But it's also not like there aren't already 5 or more open source projects > that do a similar thing better already. > > On Sun, Sep 8, 2019, 12:03 PM Antoine Pitrou <solipsis(a)pitrou.net> wrote: > >> >> How is your approach different from, say, Cython, Nuitka or Pythran? >> >> Regards >> >> Antoine. >> >> >> On Sun, 08 Sep 2019 15:56:04 -0000 >> "Mark @pysoniq" <mark(a)pysoniq.com> wrote: >>> Hi, Anders, >>> >>> The availability of a free extension every 30 days is a big benefit to >> the Python community that may not be immediately obvious. That=E2=80=99s= > not your >> standard freemium, as it has all the =E2=80=9Cfeatures=E2=80=9D of the pa= > id product -- full >> registers, multicore, SIMD and other optimizations =E2=80=93 so when we s= > ay it=E2=80=99s >> $600 per year of advanced software, that=E2=80=99s true. Our view is tha= > t the free >> extension every 30 days can make a huge difference to a developer with >> funding limitations (like us). If that free extension makes their projec= > t >> much more successful, then the entire Python community benefits. >>> >>> We considered this as an open source project, but we haven=E2=80=99t do= > ne that >> for two reasons: >>> >>> We have looked for and not found a large enough community of volunteers >> who have the skills to translate Python directly to assembly language >> without intermediate representation, and optimize the instructions, to ma= > ke >> it open source. >>> >>> Open source projects are often very underfunded and don=E2=80=99t have = > enough >> volunteers even from a larger pool of possible people. For example, at >> PyCon 2019 Victor Stinner eloquently discussed the funding problems at >> python.org =E2=80=93 a shrinking volunteer base and growing issues list. >>> >>> If I am wrong and there is a large enough group with the requisite >> skills, then of course we=E2=80=99re very open to the idea of open source= > , but the >> technologies used are very leading edge. And again, if you view it with >> nuance, the $600 a year (12 extensions) could make a huge difference to a= > n >> under-funded project, of which there are many! >>> >>> Mark >>> _______________________________________________ >>> Python-ideas mailing list -- python-ideas(a)python.org >>> To unsubscribe send an email to python-ideas-leave(a)python.org >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/VTI= > ZHUNUMKM7VTVMUCXP6LCZFKVSBUX5/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/3WZ= > Z7LYLN3DCDMQZASOSBLSVDUDSBWVO/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > --00000000000007eea505920d2ba1 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"auto"><div>Also PyPy and Numba.</div><div dir=3D"auto"><br></di= > v><div dir=3D"auto">Cython actually seems a bit different. Without annotati= > ons in a superset language, Cython programs mostly just use the same CPytho= > n runtime libraries. However, with a few type annotations sprinkled in (but= > not actual Python syntax), it can get big speedups).</div><div dir=3D"auto= > "><br></div><div dir=3D"auto">PyPy actually tried to do direct-to-machine-c= > ode for a while. But my understanding is that they decided=E2=80=94as did N= > umba=E2=80=94that building on top of the work of LLVM was more effective (a= > nd more cross-architecture).</div><div dir=3D"auto"><br></div><div dir=3D"a= > uto">Obviously, the ad for a commercial product leaves a bad taste in my mo= > uth. But it's also not like there aren't already 5 or more open sou= > rce projects that do a similar thing better already.<br><br><div class=3D"g= > mail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Sep = > 8, 2019, 12:03 PM Antoine Pitrou <<a href=3D"mailto:solipsis@pitrou.net"= >> solipsis(a)pitrou.net</a>> wrote:<br></div><blockquote class=3D"gmail_quo= > te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= >> <br> > How is your approach different from, say, Cython, Nuitka or Pythran?<br> > <br> > Regards<br> > <br> > Antoine.<br> > <br> > <br> > On Sun, 08 Sep 2019 15:56:04 -0000<br> > "Mark @pysoniq" <<a href=3D"mailto:mark@pysoniq.com" target=3D= > "_blank" rel=3D"noreferrer">mark(a)pysoniq.com</a>> wrote:<br> > > Hi, Anders, <br> > > <br> > > The availability of a free extension every 30 days is a big benefit to= > the Python community that may not be immediately obvious.=C2=A0 That=E2=80= > =99s not your standard freemium, as it has all the =E2=80=9Cfeatures=E2=80= > =9D of the paid product -- full registers, multicore, SIMD and other optimi= > zations =E2=80=93 so when we say it=E2=80=99s $600 per year of advanced sof= > tware, that=E2=80=99s true.=C2=A0 Our view is that the free extension every= > 30 days can make a huge difference to a developer with funding limitations= > (like us).=C2=A0 If that free extension makes their project much more succ= > essful, then the entire Python community benefits.=C2=A0 <br> > > <br> > > We considered this as an open source project, but we haven=E2=80=99t d= > one that for two reasons:=C2=A0 <br> > > <br> > > We have looked for and not found a large enough community of volunteer= > s who have the skills to translate Python directly to assembly language wit= > hout intermediate representation, and optimize the instructions, to make it= > open source.<br> > > <br> > > Open source projects are often very underfunded and don=E2=80=99t have= > enough volunteers even from a larger pool of possible people.=C2=A0 For ex= > ample, at PyCon 2019 Victor Stinner eloquently discussed the funding proble= > ms at <a href=3D"http://python.org" rel=3D"noreferrer noreferrer" target=3D= > "_blank">python.org</a> =E2=80=93 a shrinking volunteer base and growing is= > sues list.=C2=A0 <br> > > <br> > > If I am wrong and there is a large enough group with the requisite ski= > lls, then of course we=E2=80=99re very open to the idea of open source, but= > the technologies used are very leading edge.=C2=A0 And again, if you view = > it with nuance, the $600 a year (12 extensions) could make a huge differenc= > e to an under-funded project, of which there are many!<br> > > <br> > > Mark<br> > > _______________________________________________<br> > > Python-ideas mailing list -- <a href=3D"mailto:python-ideas@python.org= > " target=3D"_blank" rel=3D"noreferrer">python-ideas(a)python.org</a><br> > > To unsubscribe send an email to <a href=3D"mailto:python-ideas-leave@p= > ython.org" target=3D"_blank" rel=3D"noreferrer">python-ideas-leave(a)python.o= > rg</a><br> > > <a href=3D"https://mail.python.org/mailman3/lists/python-ideas.python.= > org/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://mail.python.o= > rg/mailman3/lists/python-ideas.python.org/</a><br> > > Message archived at <a href=3D"https://mail.python.org/archives/list/p= > ython-ideas(a)python.org/message/VTIZHUNUMKM7VTVMUCXP6LCZFKVSBUX5/" rel=3D"no= > referrer noreferrer" target=3D"_blank">https://mail.python.org/archives/lis= > t/python-ideas(a)python.org/message/VTIZHUNUMKM7VTVMUCXP6LCZFKVSBUX5/</a><br> > > Code of Conduct: <a href=3D"http://python.org/psf/codeofconduct/" rel= > =3D"noreferrer noreferrer" target=3D"_blank">http://python.org/psf/codeofco= > nduct/</a><br> > <br> > _______________________________________________<br> > Python-ideas mailing list -- <a href=3D"mailto:python-ideas@python.org" tar= > get=3D"_blank" rel=3D"noreferrer">python-ideas(a)python.org</a><br> > To unsubscribe send an email to <a href=3D"mailto:python-ideas-leave@python= > .org" target=3D"_blank" rel=3D"noreferrer">python-ideas-leave(a)python.org</a= >> <br> > <a href=3D"https://mail.python.org/mailman3/lists/python-ideas.python.org/"= > rel=3D"noreferrer noreferrer" target=3D"_blank">https://mail.python.org/ma= > ilman3/lists/python-ideas.python.org/</a><br> > Message archived at <a href=3D"https://mail.python.org/archives/list/python= > -ideas(a)python.org/message/3WZZ7LYLN3DCDMQZASOSBLSVDUDSBWVO/" rel=3D"norefer= > rer noreferrer" target=3D"_blank">https://mail.python.org/archives/list/pyt= > hon-ideas(a)python.org/message/3WZZ7LYLN3DCDMQZASOSBLSVDUDSBWVO/</a><br> > Code of Conduct: <a href=3D"http://python.org/psf/codeofconduct/" rel=3D"no= > referrer noreferrer" target=3D"_blank">http://python.org/psf/codeofconduct/= > </a><br> > </blockquote></div></div></div> > > --00000000000007eea505920d2ba1-- > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Python-ideas mailing list -- python-ideas(a)python.org > To unsubscribe send an email to python-ideas-leave(a)python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > > ------------------------------ > > End of Python-ideas Digest, Vol 154, Issue 27 > *********************************************

1 year, 7 months

Add a "block" option to Executor.submit

by Chris Simmons

I have a script that uploads files to Google Drive. It presently performs the uploads serially, but I want to do the uploads in parallel--with a reasonable number of simultaneous uploads--and see if that improves performance. I think that an Executor is the best way to accomplish this task. The trouble is that there's no reason for my script to continue queuing uploads while all of the Executor's workers are busy. In theory, if the number of files to upload is large enough, trying to queue all of them could cause the process to run out of memory. Even if it didn't run out of memory, it could consume an excessive amount of memory. It might be a good idea to add a "block" option to Executor.submit (https://docs.python.org/3/library/concurrent.futures.html#concurrent.future…) that allows the caller to block until a worker is free to handle the request. I believe that this would be trivial to implement by passing the "block" option through to the Executor's internal Queue.put call (https://github.com/python/cpython/blob/242c26f53edb965e9808dd918089e664c022…).

1 year, 7 months

Re: Conditional dict declarations

by Brandt Bucher

Just to be clear, PEP 584 (dictionary operators) is currently in draft form and is undergoing a new round of revisions. Nothing has been finalized, much less approved. Brandt

1 year, 7 months

Add a "block" option to Executor.submit

by Chris Simmons

1 year, 7 months

Re: Add a "block" option to Executor.submit

by Bar Harel

> > I must ask again about the actual necessity of adding a blocking call to executor.submit in that particular case. If I may intervene, the issue we're discussing about is frequently encountered with asyncio: You can have an enormous queue of clients or requests, creating a coroutine for each one of them, and using asyncio.gather to finish them all. Doing so would cause your memory to spike, and bad things to happen. The way you solve it is with a semaphore mentioned earlier. It's a standard mechanism, to be used in cases of asynchronous work, regardless of the underlying library. I believe adding a blocking submit, will create a different codebase, or way of thinking, which depends on the underlying library, specifically futures.concurrent in our case, and won't offer an advantage strong enough to justify it. As of now, you use the same constructs, no matter what kind of asynchronous work you do. Why change it? Sincerely, Bar Harel

1 year, 7 months

Add a `dig` method to dictionaries supporting the retrieval of nested keys

by j_livermont＠yahoo.com

I did some searching to see if this has already been proposed before, but didn't find any evidence that it has. If so, let me know and I'll go away :) One of the tasks that I encounter frequently enough is retrieving a nested key from a nested collection of dictionaries (a dictionary of dictionaries that can be any number of layers deep). There are multiple ways of tackling this, normally done with `reduce()`, iterative looping or chained `get()`s and then handling `None`, `KeyError` or `AttributeError` appropriately. I'd like to avoid this extra code and logic and have a built-in method to facilitate this common data access pattern. I'd like to propose that we add a `dig()` method to dictionaries analogous to Ruby's `dig()` method for Ruby Hashes (reference: https://ruby-doc.org/core-2.6.0.preview2/Hash.html#method-i-dig). Initially, I'd suggest that we only support nested dictionaries, but we could also support lists and other collection types as Ruby does if we really want to. Similar to the existing `get()` method on dictionaries, I'd propose that the method return `None` if any of the keys in the chain is not found, avoiding `KeyError`. Thoughts?

1 year, 7 months

Custom string prefixes

by stpasha＠gmail.com

In Python strings are allowed to have a number of special prefixes: b'', r'', u'', f'' + their combinations. The proposal is to allow arbitrary (or letter-only) user-defined prefixes as well. Essentially, a string prefix would serve as a decorator for a string, allowing the user to impose a special semantics of their choosing. There are quite a few situations where this can be used: - Fraction literals: `frac'123/4567'` - Decimals: `dec'5.34'` - Date/time constants: `t'2019-08-26'` - SQL expressions: `sql'SELECT * FROM tbl WHERE a=?'.bind(a=...)` - Regular expressions: `rx'[a-zA-Z]+'` - Version strings: `v'1.13.0a'` - etc. This proposal has been already discussed before, in 2013: https://mail.python.org/archives/list/python-ideas@python.org/thread/M3OLUU… The opinions were divided whether this is a useful addition. The opponents mainly argued that as this only "saves a couple of keystrokes", there is no need to overcomplicate the language. It seems to me that now, 6 years later, that argument can be dismissed by the fact that we had, in fact, added new prefix "f" to the language. Note how the "format strings" would fall squarely within this framework if they were not added by now. In addition, I believe that "saving a few keystroked" is a worthy goal if it adds considerable clarity to the expression. Readability counts. Compare: v"1.13.0a" v("1.13.0a") To me, the former expression is far easier to read. Parentheses, especially as they become deeply nested, are not easy on the eyes. But, even more importantly, the first expression much better conveys the *intent* of a version string. It has a feeling of an immutable object. In the second case the string is passed to the constructor, but the string has no meaning of its own. As such, the second expression feels artificial. Consider this: if the feature already existed, how *would* you prefer to write your code? The prefixes would also help when writing functions that accept different types of their argument. For example: collection.select("abc") # find items with name 'abc' collection.select(rx"[abc]+") # find items that match regular expression I'm not discussing possible implementation of this feature just yet, we can get to that point later when there is a general understanding that this is worth considering.

1 year, 7 months

Adding support for adequately tagging AIX (pep425) to support distributed wheels

by Michael

Goal - using wheels rather than RPM and/or installp formats for distributing binary modules Why bother? One reason (there are likely more) - using wheels means packages/modules can be loaded in a virtualenv rather than require they are first loaded in the system environment using installp/rpm/yum (with root authority). This alone has been reason enough for me to do the research. Introduction The use of pip and wheels is commonplace in the worlds of Linux, macOS and Windows. Not so for AIX. Not because it couldn't be commonplace. The current situation for AIX is comparable to the initial issue Linux was facing when PEP513 was written: "Currently, distribution of binary Python extensions for Windows and OS X is straightforward. ... For Linux, the situation is much more delicate. ... Build tools using PEP 425 platform tags [3] do not track information about the particular Linux distribution or installed system libraries, and instead assign all wheels the too-vague linux_i686 or linux_x86_64 tags. Because of this ambiguity, ..." The root cause for the *ambiguity* that Linux systems had is not the ambiguity that AIX faces. AIX has provided a consistent way to "tag" it's runtime environment since at least 2007 (AIX 5.3 TL7). Since that time IBM AIX has also *guaranteed* binary compatibility for migration of applications from old to new OS levels. I would like to see these tags added - at a minimum that they can be retrieved by something such as sysconfig.get_var('AIC_BLD_TAG'). It would be "nice" to see sysconfig.get_platform() updated to include these values from the running system. Further, while pip related tools can add the "bitness" to the platform tags I would like to see something added to the AIX get_platform() tag (b32, ppc, aix32), (b64, ppc64, aix64) for 32 and 64 bit operations, respectively - as that is a "running" environment attribute. Open to other ideas on what the bitness tag should be. IMHO - anything is better than nothing. Maybe this could be considered a bug rather than as a new feature. Thank you for your feedback. Michael

1 year, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas September 2019