From jcrmatos at gmail.com Fri Feb 1 03:26:03 2019 From: jcrmatos at gmail.com (=?UTF-8?Q?Jo=c3=a3o_Matos?=) Date: Fri, 1 Feb 2019 08:26:03 +0000 Subject: [Python-ideas] Option of running shell/console commands inside the REPL Message-ID: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> Hello, Consider adding the option of running shell/console commands inside the REPL. Something like >>>!dir Best regards, Jo?o Matos -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3988 bytes Desc: S/MIME Cryptographic Signature URL: From steve at pearwood.info Fri Feb 1 04:24:31 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 1 Feb 2019 20:24:31 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> Message-ID: <20190201092430.GS1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 08:26:03AM +0000, Jo?o Matos wrote: > Hello, > > Consider adding the option of running shell/console commands inside the > REPL. > Something like > >>>!dir That's a pretty big change, arguably best left for a third-party REPL like iPython (which already supports "magic" commands using ! and ? syntax). It is hard to tell precisely where to draw the line between adding useful functionality to the standard Python interpreter, and where to leave it for "advanced" REPLs or IDEs like iPython. My personal opinion is that specifically supporting shell commands crosses that line, but adding a REPL hook for ! commands which the user can customise does not. Hypothetically speaking, the Python interactive interpreter, and *only* the interactive interpreter, might define hooks for lines starting with a leading ! or ? and users could define their own magic functions for those. Or one could use the code module to define your own custom REPL, and automatically run that on startup: https://docs.python.org/3/library/code.html Actually, adding a code.InteractiveConsole subclass with hooks for lines beginning with ! and ? might be a nice addition to the stdlib without adding complexity to the builtin interpreter. -- Steve From mmueller at python-academy.de Fri Feb 1 04:11:00 2019 From: mmueller at python-academy.de (=?UTF-8?Q?Mike_M=c3=bcller?=) Date: Fri, 1 Feb 2019 10:11:00 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> Message-ID: Am 01.02.19 um 09:26 schrieb Jo?o Matos: > Hello, > > > Consider adding the option of running shell/console commands inside the REPL. > Something like >>>>!dir IPython provides exactly this: pip install ipython than start it with : ipython Get an overview of features with: In [1]: %quickref Mike > > > Best regards, > > Jo?o Matos > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > From lele at metapensiero.it Fri Feb 1 06:14:44 2019 From: lele at metapensiero.it (Lele Gaifax) Date: Fri, 01 Feb 2019 12:14:44 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> Message-ID: <87k1ijep5n.fsf@metapensiero.it> Further magic comes with https://pypi.org/project/xonsh/ ciao, lele. -- nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. lele at metapensiero.it | -- Fortunato Depero, 1929. From jamtlu at gmail.com Fri Feb 1 09:07:14 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 1 Feb 2019 09:07:14 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <87k1ijep5n.fsf@metapensiero.it> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> Message-ID: I always use ptipython (ptpython shell over the ipython console) for my REPLs. The built-in python repl is not *batteries included* in the sense that it already has what you need to explore the language. I wonder, what do the python committers think about including a stripped-down version of ipython and ptpython in the built-in python? On Fri, Feb 1, 2019 at 6:15 AM Lele Gaifax wrote: > Further magic comes with https://pypi.org/project/xonsh/ > > ciao, lele. > -- > nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri > real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. > lele at metapensiero.it | -- Fortunato Depero, 1929. > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenlhilton at gmail.com Fri Feb 1 09:24:22 2019 From: kenlhilton at gmail.com (Ken Hilton) Date: Fri, 1 Feb 2019 22:24:22 +0800 Subject: [Python-ideas] Option of running shell/console commands inside the REPL Message-ID: Hi, As a workaround/alternative, you can just do >>> import os >>> os.system('dir') Sincerely, Ken Hilton; -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at trueblade.com Fri Feb 1 09:25:43 2019 From: eric at trueblade.com (Eric V. Smith) Date: Fri, 1 Feb 2019 09:25:43 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> Message-ID: On 2/1/2019 9:07 AM, James Lu wrote: > I always use ptipython (ptpython shell over the ipython console) for > my REPLs. The built-in python repl is not /batteries included/ in the > sense that it already has what you need to explore the language. > > I wonder, what do the python committers think about including a > stripped-down version of ipython and ptpython in the built-in python? I'm opposed to it. I think the current situation is fine, where CPython ships with a basic REPL, and other REPLs exist. I don't want to see any complexity added to CPython. I'm not opposed to hooks to make it easier for third parties to add functionality to the CPython REPL, but I'd have to see how they complicate things before making up my mind. Eric > > On Fri, Feb 1, 2019 at 6:15 AM Lele Gaifax > wrote: > > Further magic comes with https://pypi.org/project/xonsh/ > > ciao, lele. > -- > nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri > real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. > lele at metapensiero.it ? | ? ? ? ?-- > Fortunato Depero, 1929. > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirillbalunov at gmail.com Fri Feb 1 11:02:30 2019 From: kirillbalunov at gmail.com (Kirill Balunov) Date: Fri, 1 Feb 2019 19:02:30 +0300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190131232307.GR1834@ando.pearwood.info> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: ??, 1 ????. 2019 ?. ? 02:24, Steven D'Aprano : > On Thu, Jan 31, 2019 at 09:51:20AM -0800, Chris Barker via Python-ideas > wrote: > > > I do a lot of numerical programming, and used to use MATLAB and now > numpy a > > lot. So I am very used to "vectorization" -- i.e. having operations that > > work on a whole collection of items at once. > [...] > > You can imagine that for more complex expressions the "vectorized" > approach > > can make for much clearer and easier to parse code. Also much faster, > which > > is what is usually talked about, but I think the readability is the > bigger > > deal. > > Julia has special "dot" vectorize operator that looks like this: > > L .+ 1 # adds 1 to each item in L > > func.(L) # calls f on each item in L > > https://julialang.org/blog/2017/01/moredots > > The beauty of this is that you can apply it to any function or operator > and the compiler will automatically vectorize it. The function doesn't > have to be written to specifically support vectorization. > > IMO, the beauty of vector type is that it contains homogeneous data. Therefore, it allows you to ensure that the method is present for each element in the vector. The first given example is what numpy is all about and without some guarantee that L consists of homogeneous data it hardly make sense. The second one is just `map`. So I can't catch what you are proposing: 1. To make an operator form of `map`. 2. To pull numpy into stdlib. 3. Or something else, which is not obvious to me from the examples given. With kind regards, -gdg > > > So what does this have to do with the topic at hand? > > > > I know that when I'm used to working with numpy and then need to do some > > string processing or some such, I find myself missing this > "vectorization" > > -- if I want to do the same operation on a whole bunch of strings, why > do I > > need to write a loop or comprehension or map? that is: > > > > [s.lower() for s in a_list_of_strings] > > > > rather than: > > > > a_list_of_strings.lower() > > Using Julia syntax, that might become a_list_of_strings..lower(). If you > don't like the double dot, perhaps str.lower.(a_list_of_strings) would > be less ugly. > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamtlu at gmail.com Fri Feb 1 11:40:37 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 1 Feb 2019 11:40:37 -0500 Subject: [Python-ideas] Clearer communication Message-ID: A lot of the traffic on this email list is people saying ?I don?t understand? or ?that?s not what I meant? or trying to re-explain. A lot of ?-1?s are really ?I don?t see the usefulness of this?. So I want an open discussion on: How can we communicate clearer? From robertve92 at gmail.com Fri Feb 1 12:21:07 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Fri, 1 Feb 2019 18:21:07 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: That's a nice question ! The main thing is "is this list more EmailLike or MessengerLike" When I speak on Messenger (or any instantaneous conversation software) I send a lot of very small messages, like "+1", it's interactive, I'm expecting a short answer. If I say something stupid, I undo, if I can't undo because the delay of my client is done, I send another message beginning with "Oops" or something obvious. It's the EAFP (Easier to ask for forgiveness than Permission) style. The point is "looking ar my first few words, people understand the message" When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before you Leap), I write a long, but structured message, such that people see first the structure, (intro, body, conclusion), and look in the message if they want. On Fri, 1 Feb 2019, 17:40 James Lu A lot of the traffic on this email list is people saying ?I don?t > understand? or ?that?s not what I meant? or trying to re-explain. A lot of > ?-1?s are really ?I don?t see the usefulness of this?. > > > So I want an open discussion on: How can we communicate clearer? > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Fri Feb 1 12:42:33 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Fri, 1 Feb 2019 18:42:33 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: I'm kinda new to those mailing lists and those are the only ones I ever subscribed so I'm a bit in the audience you're targeting James. What I think is bad using mailing list it's the absence of votes. I'd often like to just hit a "+1" button for some mails just to say to the author I'm with him and I think s.he's ideas are great. In some of the recent threads, some of the ideas I agreed with were just smashed by others. I couldn't give my two cents and the debate juste ended and I couldn't say the author I was behind him.er. Another thing I think is not good is the absence of little chit-chat and editing. Actually, a lot of emails are just explanations of what the authors meant. That's pretty spammy and a few messages exchanged + editing would correct this spammy thing. In another hand, I think mailing lists are great to avoid short and useless messages. There's no spammy message like "I'm ok" which could be replaced by just a "+1" button. It forces us using LBYL principle (@poke Robert) and it (imho) better fills the needs of such discussions. As you may have get it, I'd rather a forum like thing rather than mailing lists but mailings lists are great. Le ven. 1 f?vr. 2019 ? 18:22, Robert Vanden Eynde a ?crit : > That's a nice question ! > > The main thing is "is this list more EmailLike or MessengerLike" > > When I speak on Messenger (or any instantaneous conversation software) I > send a lot of very small messages, like "+1", it's interactive, I'm > expecting a short answer. > > If I say something stupid, I undo, if I can't undo because the delay of my > client is done, I send another message beginning with "Oops" or something > obvious. It's the EAFP (Easier to ask for forgiveness than Permission) > style. > > The point is "looking ar my first few words, people understand the message" > > When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before > you Leap), I write a long, but structured message, such that people see > first the structure, (intro, body, conclusion), and look in the message if > they want. > > On Fri, 1 Feb 2019, 17:40 James Lu >> A lot of the traffic on this email list is people saying ?I don?t >> understand? or ?that?s not what I meant? or trying to re-explain. A lot of >> ?-1?s are really ?I don?t see the usefulness of this?. >> >> >> So I want an open discussion on: How can we communicate clearer? >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashafer at pm.me Fri Feb 1 12:43:54 2019 From: ashafer at pm.me (Alex Shafer) Date: Fri, 01 Feb 2019 17:43:54 +0000 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: Agreed, thanks James for asking. And thanks for bringing up the issue of communication mode in different mediums, Robert. I personally think the type of discussions taking place on this list would be better suited to a more interactive or conversational medium. Is there already, or would anyone be opposed to the creation of a #python-ideas on a large IRC network? I'd hope discussions there can have the same weight, merit, community involvement, and potential for PEP-tracking ideas. I think accommodating different people's best communication modes is essential to the continued development of any community and project. -------- Original Message -------- On Feb 1, 2019, 10:21, Robert Vanden Eynde wrote: > That's a nice question ! > > The main thing is "is this list more EmailLike or MessengerLike" > > When I speak on Messenger (or any instantaneous conversation software) I send a lot of very small messages, like "+1", it's interactive, I'm expecting a short answer. > > If I say something stupid, I undo, if I can't undo because the delay of my client is done, I send another message beginning with "Oops" or something obvious. It's the EAFP (Easier to ask for forgiveness than Permission) style. > > The point is "looking ar my first few words, people understand the message" > > When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before you Leap), I write a long, but structured message, such that people see first the structure, (intro, body, conclusion), and look in the message if they want. > > On Fri, 1 Feb 2019, 17:40 James Lu >> A lot of the traffic on this email list is people saying ?I don?t understand? or ?that?s not what I meant? or trying to re-explain. A lot of ?-1?s are really ?I don?t see the usefulness of this?. >> >> So I want an open discussion on: How can we communicate clearer? >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Fri Feb 1 12:42:01 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 04:42:01 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: <20190201174201.GT1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 06:21:07PM +0100, Robert Vanden Eynde wrote: > That's a nice question ! > > The main thing is "is this list more EmailLike or MessengerLike" This is a perfect example of the problem that James is referring to. I honestly cannot tell if you are being rhetorical, or if you are so technically naive that you genuinely don't know that this is an email mailing list rather than instant messenger or IRC or some other form of instantaneous chat. [...] > When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before > you Leap), I write a long, but structured message, such that people see > first the structure, (intro, body, conclusion), and look in the message if > they want. That doesn't sound like the sorts of messages you have been sending here recently. https://mail.python.org/pipermail/python-ideas/2019-January/055022.html https://mail.python.org/pipermail/python-ideas/2019-January/055028.html https://mail.python.org/pipermail/python-ideas/2019-January/055032.html I don't mean this as a criticism of such short posts. Sometimes all that needs to be said is a single sentence. But when you describe your posting style one way, but actually post another way, that is precisely the sort of confusing lack of clarity that this thread is about. -- Steve From mertz at gnosis.cx Fri Feb 1 12:47:58 2019 From: mertz at gnosis.cx (David Mertz) Date: Fri, 1 Feb 2019 12:47:58 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: On Fri, Feb 1, 2019 at 12:43 PM Adrien Ricocotam wrote: > What I think is bad using mailing list it's the absence of votes. I'd > often like to just hit a "+1" button for some mails just to say to the > author I'm with him and I think s.he's ideas are great. > I feel like the strongest virtue of mailing lists is the absence of votes. Various chat systems where you can add a "thumbs up" or "smile" or the like encourage laziness and content-free interaction. On a mailing list, for the most part, we encourage people to formulate complete opinions supported by reasons and arguments. That is what python-ideas should be. It should not be a democracy or a voting system. That said, obviously sometimes people do just reply with +1 to something. I do that myself at times. There are times when that really is an appropriate reply, but I think it should be discouraged as the default answer style. Yours, David... -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertve92 at gmail.com Fri Feb 1 12:49:35 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Fri, 1 Feb 2019 18:49:35 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: Email Can be fast, as long as it is structured. The list only impose the structure of "Thread" ie. Two mails are in the same thread if they have the same subject. Each thread can have it's own format. Email use the quoting mechanism using leading ">" ane generally people do not like html (switch to TextOnly in your mail client if it helps you). Therefore inline images are not used often (one prefer). In the end, anyone can see the list of email, by date, or by thread, on https://mail.python.org/pipermail/python-ideas/2019-February/thread.html On Fri, 1 Feb 2019, 18:42 Adrien Ricocotam Did you use inclusive writing ? :D do you speak French ? :D Generally I suggest using the middle dot, "?" easily accessible by copy paste, or by long pressing the "-" key on android. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertve92 at gmail.com Fri Feb 1 12:59:33 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Fri, 1 Feb 2019 18:59:33 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190201174201.GT1834@ando.pearwood.info> References: <20190201174201.GT1834@ando.pearwood.info> Message-ID: > > > I honestly cannot tell if you are being rhetorical, or if you are > so technically naive that you genuinely don't know that this is an email > mailing list rather than instant messenger or IRC or some other form of > instantaneous chat. > Both :p Newcomers that never spoke on a forum are sometimes lost, they don't see the structure. Therefore I'm helping those newcomers, and the old timer will be like "yeah, he technically defines terms that are obvious for me". When I was a newcomer on this list, I was lost, people said things like "don't up post" or "don't put the answer below" or "answer inline" in a jargon I didn't know about. I'm CS teacher, and I see everyday that things not said explicitly create misunderstanding to newcomers. > [...] > > When I speak on TraditionalDifferedEmail, I'm more like LBYL (Look before > > you Leap), I write a long, but structured message, such that people see > > first the structure, (intro, body, conclusion), and look in the message > if > > they want. > > That doesn't sound like the sorts of messages you have been sending > here recently. > Yep, depending on the thread, I'm either type EAFP or LBYL, and I think people can easily guess which type :) (long message = LBYL). However, I don't always "read myself two times" before I send (because of my EAFP nature) so my last mail for example was LBYL but has some spelling mistakes. -- And I guess people will ask if they are not sure. I don't mean this as a criticism of such short posts. Sometimes all that > needs to be said is a single sentence. Agreed !! But when you describe your > posting style one way, but actually post another way, that is precisely > the sort of confusing lack of clarity that this thread is about. > Indeed, mixing standards is bad, but on the other hand, people can think "Robert is Eafp", "Robert is more LBYL when writing long messages") -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.eliziario at gmail.com Fri Feb 1 13:02:31 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 1 Feb 2019 16:02:31 -0200 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: +1 votes hardly add anything to a technical discussion, and in the contrary, can and do easily lead to a dysfunctional decision style. If you agree with someone else's idea, you probably have some rational arguments behind it, some hard evidence that has not yet been discussed and that could change the course of the discussions. If you can't come up with even a single reason why you like a proposal, probably you didn't think too much about, and so, your +1 would be an uninformed vote. And last, this list is not a decision instance for python, it is just a place where people can share ideas about it, but the final decisions are not meant to be taken here. Em sex, 1 de fev de 2019 ?s 15:49, David Mertz escreveu: > On Fri, Feb 1, 2019 at 12:43 PM Adrien Ricocotam > wrote: > >> What I think is bad using mailing list it's the absence of votes. I'd >> often like to just hit a "+1" button for some mails just to say to the >> author I'm with him and I think s.he's ideas are great. >> > > I feel like the strongest virtue of mailing lists is the absence of votes. > > Various chat systems where you can add a "thumbs up" or "smile" or the > like encourage laziness and content-free interaction. On a mailing list, > for the most part, we encourage people to formulate complete opinions > supported by reasons and arguments. That is what python-ideas should be. > It should not be a democracy or a voting system. > > That said, obviously sometimes people do just reply with +1 to something. > I do that myself at times. There are times when that really is an > appropriate reply, but I think it should be discouraged as the default > answer style. > > Yours, David... > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.eliziario at gmail.com Fri Feb 1 13:05:34 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 1 Feb 2019 16:05:34 -0200 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: +1 votes hardly add anything to a technical discussion, and in the contrary, can and do easily lead to a dysfunctional decision style. If you agree with someone else's idea, you probably have some rational arguments behind it, some hard evidence that has not yet been discussed and that could change the course of the discussions. If you can't come up with even a single reason why you like a proposal, probably you didn't think too much about, and so, your +1 would be an uninformed vote. And last, this list is not a decision instance for python, it is just a place where people can share ideas about it, but the final decisions are not meant to be taken here. Em sex, 1 de fev de 2019 ?s 16:02, Marcos Eliziario < marcos.eliziario at gmail.com> escreveu: > +1 votes hardly add anything to a technical discussion, and in the > contrary, can and do easily lead to a dysfunctional decision style. > If you agree with someone else's idea, you probably have some rational > arguments behind it, some hard evidence that has not yet been discussed and > that could change the course of the discussions. > If you can't come up with even a single reason why you like a proposal, > probably you didn't think too much about, and so, your +1 would be an > uninformed vote. > And last, this list is not a decision instance for python, it is just a > place where people can share ideas about it, but the final decisions are > not meant to be taken here. > > Em sex, 1 de fev de 2019 ?s 15:49, David Mertz escreveu: > >> On Fri, Feb 1, 2019 at 12:43 PM Adrien Ricocotam >> wrote: >> >>> What I think is bad using mailing list it's the absence of votes. I'd >>> often like to just hit a "+1" button for some mails just to say to the >>> author I'm with him and I think s.he's ideas are great. >>> >> >> I feel like the strongest virtue of mailing lists is the absence of votes. >> >> Various chat systems where you can add a "thumbs up" or "smile" or the >> like encourage laziness and content-free interaction. On a mailing list, >> for the most part, we encourage people to formulate complete opinions >> supported by reasons and arguments. That is what python-ideas should be. >> It should not be a democracy or a voting system. >> >> That said, obviously sometimes people do just reply with +1 to >> something. I do that myself at times. There are times when that really is >> an appropriate reply, but I think it should be discouraged as the default >> answer style. >> >> Yours, David... >> >> -- >> Keeping medicines from the bloodstreams of the sick; food >> from the bellies of the hungry; books from the hands of the >> uneducated; technology from the underdeveloped; and putting >> advocates of freedom in prisons. Intellectual property is >> to the 21st century what the slave trade was to the 16th. >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Marcos Elizi?rio Santos > mobile/whatsapp/telegram: +55(21) 9-8027-0156 > skype: marcos.eliziario at gmail.com > linked-in : https://www.linkedin.com/in/eliziario/ > > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamtlu at gmail.com Fri Feb 1 13:10:26 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 1 Feb 2019 13:10:26 -0500 Subject: [Python-ideas] How do ideas on this mailing list turn into features? Message-ID: How do ideas on this mailing list turn into features? What is the typical roadmap? Can this process be documented somewhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoffspear at gmail.com Fri Feb 1 13:23:18 2019 From: geoffspear at gmail.com (Geoffrey Spear) Date: Fri, 1 Feb 2019 13:23:18 -0500 Subject: [Python-ideas] How do ideas on this mailing list turn into features? In-Reply-To: References: Message-ID: https://devguide.python.org/#proposing-changes-to-python-itself On Fri, Feb 1, 2019, 1:12 PM James Lu How do ideas on this mailing list turn into features? What is the typical > roadmap? Can this process be documented somewhere? > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.eliziario at gmail.com Fri Feb 1 13:23:23 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 1 Feb 2019 16:23:23 -0200 Subject: [Python-ideas] How do ideas on this mailing list turn into features? In-Reply-To: References: Message-ID: Basically the process is described here. Of course, as in any Open Source projects, any ideas have a lot more chance of being considered if they are accompanied by a patch with at least an example, partial but working implementation of proposed feature. https://www.python.org/dev/peps/pep-0001/ Em sex, 1 de fev de 2019 ?s 16:12, James Lu escreveu: > How do ideas on this mailing list turn into features? What is the typical > roadmap? Can this process be documented somewhere? > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 13:35:15 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 12:35:15 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: I've pitched this before but gotten little feedback (especially positive feedback), but I think a Reddit-style forum would be a pretty vast improvement. We could easily start a python_ideas subreddit to try it out. I know the google group presents threaded conversations, but I've run into enough bugs trying to use that platform that I now only interact with python-ideas via my gmail account, and threads are flattened here. Also, a Reddit-style forum has voting built in. As a bonus, we can write moderation bots and present useful info in the side-bar. If people find Reddit distasteful or otherwise a bad idea, maybe we can find some forum software that replicates the feature set of Reddit and host it ourselves? On Fri, Feb 1, 2019 at 10:41 AM James Lu wrote: > A lot of the traffic on this email list is people saying ?I don?t > understand? or ?that?s not what I meant? or trying to re-explain. A lot of > ?-1?s are really ?I don?t see the usefulness of this?. > > > So I want an open discussion on: How can we communicate clearer? > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Fri Feb 1 13:38:37 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 05:38:37 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: <20190201183836.GU1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 06:42:33PM +0100, Adrien Ricocotam wrote: > I'm kinda new to those mailing lists and those are the only ones I ever > subscribed so I'm a bit in the audience you're targeting James. Hi Adrien, I see that you first posted in November and haven't posted since. > What I think is bad using mailing list it's the absence of votes. I'd often > like to just hit a "+1" button for some mails just to say to the author I'm > with him and I think s.he's ideas are great. That sounds pretty spammy to me. The last thing I want to see is something (either technology or culture) encouraging people to flood the list with a bunch of content-free "+1" or "metoo!" messages. The occasional "I agree but have nothing else to say" message is okay, but I wouldn't want to see fifty a day. This isn't Facebook or Reddit, where +1 Likes cause messages to move to the top of your feed. (And thank goodness for that.) This is a technical mailing list where the worth of a proposals usually depends on merit, not the number of votes. > In some of the recent threads, > some of the ideas I agreed with were just smashed by others. I couldn't > give my two cents and the debate juste ended and I couldn't say the author > I was behind him.er. I see that the Reply button on your email client does work, so you clearly *can* give your two cents worth (which is exactly what you are doing now). And the nature of email is that you can reply to any message in your inbox, no matter how old. You can reply to a ten year old message provided you still have it available in a mail folder, resurrecting the thread. Whether it is polite to resurrect such long-dead threads, or whether anyone else will respond, are separate questions. I realise that sometimes people are busy and cannot reply immediately to a discussion. There have been times that I have not been able to respond to a thread until long after it has faded away naturally, and I have *chosen* to not respond because I decided that the discussion had been settled and I didn't care enough to restart the discussion. (Sometimes a discussion settles to "nobody can decide so the status quo wins". See Nick Coghlan's blog.) But within reason, if you have something well thought out and/or important to say, you can and should just reply to a post and say it. > Another thing I think is not good is the absence of > little chit-chat This mailing list is often too busy as it is, without encouraging chit-chat. "Hi Bob, how are the wife and kids? I've been pretty good myself, thanks for asking, but my old injury has been aching a bit. Did I ever tell you the story about that, its quite funny. What do you think of Trump's latest shocking comment? Did you see that hilarious video about a cat? Did you learn the latest trick that doctors don't want you to know? Oh, I nearly forgot, your proposal for adding GOTO to Python and removing for-loops is an awesome idea, +1." > and editing. Actually, a lot of emails are just > explanations of what the authors meant. That's pretty spammy and a few > messages exchanged + editing would correct this spammy thing. I'm confused. First you complain that "a lot of emails are just explanations of what the authors meant". That's a *good* thing, surely. This is a technical discussion list, and if a message is unclear, then explaning what you meant should make it more clear. And then you say "a few messages exchanged ... would correct this" but what do you think those messages exchanged would be if not explanations of what the authors meant? > In another hand, I think mailing lists are great to avoid short and useless > messages. There's no spammy message like "I'm ok" which could be replaced > by just a "+1" button. Which does what? Send a +1 email to a thousand people? That's pretty spammy. > It forces us using LBYL principle (@poke Robert) and > it (imho) better fills the needs of such discussions. > > As you may have get it, I'd rather a forum like thing rather than mailing > lists but mailings lists are great. Mailing lists and web forums each have their advantages and disadvantages, but in general, I find web forums far noisier and of less value. In the future this list may be migrated to Mailman 3 which includes a more modern web-forum-like interface as well as email. http://docs.mailman3.org/en/latest/userguide.html As I understand it, there have already been a few low-volume Python mailing lists migrated to Mailman 3, and if they end up being successful eventually the rest will follow. -- Steve From steve at pearwood.info Fri Feb 1 13:44:51 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 05:44:51 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> Message-ID: <20190201184450.GV1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 09:07:14AM -0500, James Lu wrote: > I always use ptipython (ptpython shell over the ipython console) for my > REPLs. The built-in python repl is not *batteries included* in the sense > that it already has what you need to explore the language. What part of the Python language do you think cannot be used in the standard Python REPL? -- Steve From jamtlu at gmail.com Fri Feb 1 13:50:02 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 1 Feb 2019 13:50:02 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190201184450.GV1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> Message-ID: It?s difficult to learn anything with a body (such as a loop or a class or a function) with the built in REPL because you can?t edit lines you?ve already written. Sent from my iPhone > On Feb 1, 2019, at 1:44 PM, Steven D'Aprano wrote: > >> On Fri, Feb 01, 2019 at 09:07:14AM -0500, James Lu wrote: >> >> I always use ptipython (ptpython shell over the ipython console) for my >> REPLs. The built-in python repl is not *batteries included* in the sense >> that it already has what you need to explore the language. > > What part of the Python language do you think cannot be used in the > standard Python REPL? > > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From steve at pearwood.info Fri Feb 1 13:55:45 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 05:55:45 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: <20190201185545.GW1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 05:43:54PM +0000, Alex Shafer via Python-ideas wrote: > Is there already, or would anyone be opposed to the creation of a > #python-ideas on a large IRC network? I'd hope discussions there can > have the same weight, merit, community involvement, and potential for > PEP-tracking ideas. That biases the community against people who aren't available to chat at the same time as the majority. E,g, people in different time zones, or who work or have other committments during which time they can't take part in the discussion. The beauty of email is that it sits in your inbox until you get a chance to respond, even if that is a few days later. In IRC, you might have a window of opportunity of a few hours. In a busy chat room, it might be a few seconds before the comment you are replying to disappears off screen into irrelevance. IRC encourages one sentence replies. There really isn't room for complex reasoning or long debates. It is good for simple answers and knee-jerk responses. -- Steve From abedillon at gmail.com Fri Feb 1 14:01:06 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 13:01:06 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190201183836.GU1834@ando.pearwood.info> References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: [Steven D'Aprano] > This isn't Facebook or Reddit, where +1 Likes cause messages to move to > the top of your feed. (And thank goodness for that.) This is a technical > mailing list where the worth of a proposals usually depends on merit, > not the number of votes. Since I just (almost simultaneously with this post) suggested giving Reddit a try, I feel obligated to defend it a little bit. 1) You might be right. It might result in lower quality discussions, but it seems like a very low barrier to entry to at least try and see. 2) You can control, to some degree, what gets to the top of your feed. In an email list, it's based on who posted last which seems hardly an improvement. 3) There are well moderated and/or cultivated subs like www.reddit.com/r/science where the votes end up being a good approximation to merit. [Steven D'Aprano] > In the future this list may be migrated to Mailman 3 which includes a > more modern web-forum-like interface as well as email. > http://docs.mailman3.org/en/latest/userguide.html Can you summarize what mailman3 brings to the table? The docs aren't very clear and have a lot of preamble. On Fri, Feb 1, 2019 at 12:39 PM Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 06:42:33PM +0100, Adrien Ricocotam wrote: > > I'm kinda new to those mailing lists and those are the only ones I ever > > subscribed so I'm a bit in the audience you're targeting James. > > Hi Adrien, I see that you first posted in November and haven't posted > since. > > > What I think is bad using mailing list it's the absence of votes. I'd > often > > like to just hit a "+1" button for some mails just to say to the author > I'm > > with him and I think s.he's ideas are great. > > That sounds pretty spammy to me. The last thing I want to see is > something (either technology or culture) encouraging people to flood the > list with a bunch of content-free "+1" or "metoo!" messages. > > The occasional "I agree but have nothing else to say" message is okay, > but I wouldn't want to see fifty a day. > > This isn't Facebook or Reddit, where +1 Likes cause messages to move to > the top of your feed. (And thank goodness for that.) This is a technical > mailing list where the worth of a proposals usually depends on merit, > not the number of votes. > > > > In some of the recent threads, > > some of the ideas I agreed with were just smashed by others. I couldn't > > give my two cents and the debate juste ended and I couldn't say the > author > > I was behind him.er. > > I see that the Reply button on your email client does work, so you > clearly *can* give your two cents worth (which is exactly what you are > doing now). > > And the nature of email is that you can reply to any message in your > inbox, no matter how old. You can reply to a ten year old message > provided you still have it available in a mail folder, resurrecting > the thread. > > Whether it is polite to resurrect such long-dead threads, or whether > anyone else will respond, are separate questions. > > I realise that sometimes people are busy and cannot reply immediately to > a discussion. There have been times that I have not been able to respond > to a thread until long after it has faded away naturally, and I have > *chosen* to not respond because I decided that the discussion had been > settled and I didn't care enough to restart the discussion. > > (Sometimes a discussion settles to "nobody can decide so the status quo > wins". See Nick Coghlan's blog.) > > But within reason, if you have something well thought out and/or > important to say, you can and should just reply to a post and say it. > > > > Another thing I think is not good is the absence of > > little chit-chat > > This mailing list is often too busy as it is, without encouraging > chit-chat. > > "Hi Bob, how are the wife and kids? I've been pretty good myself, > thanks for asking, but my old injury has been aching a bit. Did I > ever tell you the story about that, its quite funny. What do you > think of Trump's latest shocking comment? Did you see that hilarious > video about a cat? Did you learn the latest trick that doctors don't > want you to know? Oh, I nearly forgot, your proposal for adding GOTO > to Python and removing for-loops is an awesome idea, +1." > > > > and editing. Actually, a lot of emails are just > > explanations of what the authors meant. That's pretty spammy and a few > > messages exchanged + editing would correct this spammy thing. > > I'm confused. First you complain that "a lot of emails are just > explanations of what the authors meant". That's a *good* thing, surely. > This is a technical discussion list, and if a message is unclear, then > explaning what you meant should make it more clear. > > And then you say "a few messages exchanged ... would correct this" but > what do you think those messages exchanged would be if not explanations > of what the authors meant? > > > > In another hand, I think mailing lists are great to avoid short and > useless > > messages. There's no spammy message like "I'm ok" which could be replaced > > by just a "+1" button. > > Which does what? Send a +1 email to a thousand people? That's pretty > spammy. > > > It forces us using LBYL principle (@poke Robert) and > > it (imho) better fills the needs of such discussions. > > > > As you may have get it, I'd rather a forum like thing rather than mailing > > lists but mailings lists are great. > > Mailing lists and web forums each have their advantages and > disadvantages, but in general, I find web forums far noisier and of less > value. > > In the future this list may be migrated to Mailman 3 which includes a > more modern web-forum-like interface as well as email. > > http://docs.mailman3.org/en/latest/userguide.html > > As I understand it, there have already been a few low-volume Python > mailing lists migrated to Mailman 3, and if they end up being successful > eventually the rest will follow. > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Fri Feb 1 14:10:43 2019 From: mertz at gnosis.cx (David Mertz) Date: Fri, 1 Feb 2019 14:10:43 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: If any non-email system is adopted, it will exclude me, and probably many other contributors to this list. A mailing list is an appropriate and useful format. "Discussion systems" are not. On Fri, Feb 1, 2019 at 1:36 PM Abe Dillon wrote: > I've pitched this before but gotten little feedback (especially positive > feedback), but I think a Reddit-style forum would be a pretty vast > improvement. We could easily start a python_ideas subreddit to try it out. > > I know the google group presents threaded conversations, but I've run into > enough bugs trying to use that platform that I now only interact with > python-ideas via my gmail account, and threads are flattened here. Also, a > Reddit-style forum has voting built in. As a bonus, we can write moderation > bots and present useful info in the side-bar. > > If people find Reddit distasteful or otherwise a bad idea, maybe we can > find some forum software that replicates the feature set of Reddit and host > it ourselves? > > On Fri, Feb 1, 2019 at 10:41 AM James Lu wrote: > >> A lot of the traffic on this email list is people saying ?I don?t >> understand? or ?that?s not what I meant? or trying to re-explain. A lot of >> ?-1?s are really ?I don?t see the usefulness of this?. >> >> >> So I want an open discussion on: How can we communicate clearer? >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From python-ideas at mgmiller.net Fri Feb 1 13:59:56 2019 From: python-ideas at mgmiller.net (Mike Miller) Date: Fri, 1 Feb 2019 10:59:56 -0800 Subject: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS In-Reply-To: References: <20190129223001.GA92125@cskk.homeip.net> Message-ID: On 1/30/19 6:07 PM, David Mertz wrote: > On Wed, Jan 30, 2019, 4:23 PM Abe Dillon wrote: > > Consider thatmath.pi and math.e are constants that are not all caps, have > you ever been tempted to re-bind those variables? > > > I generally use 'from math import pi as PI' because the lower case is confusing > and misnamed. Another message here reminded me that the datetime classes are not named DateTime like they should be. Why not rename them, PI and E too, with suitable long-term deprecation period? (As it looks like ALL_CAPS is here to stay.) -Mike From jamtlu at gmail.com Fri Feb 1 14:18:07 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 1 Feb 2019 14:18:07 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: > I want the discussion to focus not only on technical solutions like +1 or Mailman 3, but also social ones and how to better express oneself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 14:23:30 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 13:23:30 -0600 Subject: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS In-Reply-To: References: <20190129223001.GA92125@cskk.homeip.net> Message-ID: [Mike Miller] > Another message here reminded me that the datetime classes are not named > DateTime like they should be. There are a few strange conventions in programming that seem almost backwards. In prose, we capitalize proper nouns, but rarely class-type nouns. Bullwinkle is a moose, not bullwinkle is a Moose. It seems the built-ins like int, str, list, dict, etc. get it right, then it's reversed for everything else. [Mike Miller] > Why not rename them, PI and E too, with suitable > long-term deprecation period? > (As it looks like ALL_CAPS is here to stay.) There's a Java programming guideline at my workplace that you're supposed to put "final" in-front of pretty much everything because it supposedly makes code easier to reason about. I've since found that the Java community largely supports this idea (not just my company), which raises the question, "why not make everything default to 'final' and put 'var' or something in-front of the few outliers?". My default assumption for any variable not in the immediate scope is that it's intended to be read-only unless the code I'm reading modifies it. Maybe module-level variables and class-level variables should be all caps if they're NOT constant because then I'd want them to yell at me that they're a potential hazard. Anyway, I thought others might find that to be mildly interesting food for thought. Sorry for bumping this thread again... On Fri, Feb 1, 2019 at 12:59 PM Mike Miller wrote: > > On 1/30/19 6:07 PM, David Mertz wrote: > > On Wed, Jan 30, 2019, 4:23 PM Abe Dillon > wrote: > > > > Consider thatmath.pi and math.e are constants that are not all caps, > have > > you ever been tempted to re-bind those variables? > > > > > > I generally use 'from math import pi as PI' because the lower case is > confusing > > and misnamed. > > > Another message here reminded me that the datetime classes are not named > DateTime like they should be. Why not rename them, PI and E too, with > suitable > long-term deprecation period? > > (As it looks like ALL_CAPS is here to stay.) > > -Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 1 14:33:37 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 1 Feb 2019 13:33:37 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: On 2/1/19 1:01 PM, Abe Dillon wrote: > [Steven D'Aprano] > >> This isn't Facebook or Reddit, where +1 Likes cause messages to move >> to the top of your feed. (And thank goodness for that.) This is a >> technical mailing list where the worth of a proposals usually depends >> on merit, not the number of votes. > > Since I just (almost simultaneously with this post) suggested giving > Reddit a try, I feel obligated to defend it a little bit. [...] > 2) You can control, to some degree, what gets to the top of your > feed. In an email list, it's based on who posted last which seems > hardly an improvement. A mailing list is not a feed. Whoever posted last ends up at the bottom of the thread, so that I can read threads from top to bottom in chronological order. Getting the last word in shouldn't earn a spot at the top of the list. In my email client, I do, in fact, have complete control over what gets to the [logical] "top of the list"; in a web-based forum, I have only what the forum allows. > 3) There are well moderated and/or cultivated subs like > www.reddit.com/r/science where the votes end up being a good approximation > to merit. Because the moderators understand the merit(s) of who is behind every +1 vote, or because only approved voters are allowed to vote? Dan, a decades and decades long fan of mailing lists and real email clients From eric at trueblade.com Fri Feb 1 14:43:49 2019 From: eric at trueblade.com (Eric V. Smith) Date: Fri, 1 Feb 2019 14:43:49 -0500 Subject: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS In-Reply-To: References: <20190129223001.GA92125@cskk.homeip.net> Message-ID: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> On 2/1/2019 1:59 PM, Mike Miller wrote: > > On 1/30/19 6:07 PM, David Mertz wrote: >> On Wed, Jan 30, 2019, 4:23 PM Abe Dillon > wrote: >> >> ??? Consider thatmath.pi and math.e are constants that are not all >> caps, have >> ??? you ever been tempted to re-bind those variables? >> >> I generally use 'from math import pi as PI' because the lower case is >> confusing and misnamed. > > > Another message here reminded me that the datetime classes are not named > DateTime like they should be.? Why not rename them, PI and E too, with > suitable long-term deprecation period? Because the hassle involved in making the change, supporting both for a long time, invalidating tons of working code, invalidating tutorials, migrating existing pickle files, etc. isn't worth any slight gain in consistency. > (As it looks like ALL_CAPS is here to stay.) Yes, I'd say so. Eric From tjreedy at udel.edu Fri Feb 1 15:12:42 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 1 Feb 2019 15:12:42 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> Message-ID: On 2/1/2019 1:50 PM, James Lu wrote: > It?s difficult to learn anything with a body (such as a loop or a class or a function) with the built in REPL because you can?t edit lines you?ve already written. I presume you mean that it is 'difficult to learn about compound statements and multiline simple statements with standard interactive python because one cannot edit lines already entered. True. This is one of the great advantages of IDLE and any other IDE in which one keys in and can edit a complete multiline statement before submitting it to Python to run It is also difficult to edit and rerun previously run multiline statements in the standard REPL when one must retrieve, edit, and enter previous lines one at a time. Again, IDLE and anything similar makes this much easier by retrieving and allowing the editing and resubmission of complete multiline statements. However, I don't see what this has to do with running system console commands in a Python shell. -- Terry Jan Reedy From phd at phdru.name Fri Feb 1 15:31:21 2019 From: phd at phdru.name (Oleg Broytman) Date: Fri, 1 Feb 2019 21:31:21 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> Message-ID: <20190201203121.yffztjtoxdbczmnc@phdru.name> On Fri, Feb 01, 2019 at 03:12:42PM -0500, Terry Reedy wrote: > On 2/1/2019 1:50 PM, James Lu wrote: > > It???s difficult to learn anything with a body (such as a loop or a class or a function) with the built in REPL because you can???t edit lines you???ve already written. > > However, I don't see what this has to do with running system console > commands in a Python shell. Python REPL is missing the following batteries: * Persistent history; * Syntax highlighting; * Clear separation (using, for example, different colors) between input, output and errors; * Paging of very long output/errors. > -- > Terry Jan Reedy Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 1 15:38:43 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 1 Feb 2019 14:38:43 -0600 Subject: [Python-ideas] Running Python commands from a Shell (was: Option of running shell/console commands inside the REPL) In-Reply-To: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> Message-ID: <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> On 2/1/19 2:26 AM, Jo?o Matos wrote: > Hello, > > > Consider adding the option of running shell/console commands inside the REPL. > Something like >>>>!dir I first ran into this in the days of teletypes and dumb terminals, where other programs let you run shell commands from inside them. Now the shoe appears to be on the other foot. So why not turn that around? ksh (since way back when) and bash (since 2008, according to what I read somewhere online) have "co-processes," which allow you to run a command "in the background," and send commands and receive replies from it. So I tried it with Python, but it didn't work: $ coproc P3 { python3; } $ echo 'import sys; print(sys.version)' >&${P3[1]} $ read v <&${P3[0]} [the read command just waits forever] A pile of experiments and examples from web pages later, I think it's Python and not me. My example, with suitable changes to the literal in the echo command, works with sbcl and erl, but not python3. If I start python3 as follows: $ coproc P3 { python3 | tee /tmp/P3; } then I can see the empty /tmp/P3 file, and the python3 and tee processes, but /tmp/P3 remains empty. Any ideas as to why not? Thanks, Dan From rosuav at gmail.com Fri Feb 1 15:45:43 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 2 Feb 2019 07:45:43 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190201203121.yffztjtoxdbczmnc@phdru.name> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: On Sat, Feb 2, 2019 at 7:32 AM Oleg Broytman wrote: > > On Fri, Feb 01, 2019 at 03:12:42PM -0500, Terry Reedy wrote: > > On 2/1/2019 1:50 PM, James Lu wrote: > > > It???s difficult to learn anything with a body (such as a loop or a class or a function) with the built in REPL because you can???t edit lines you???ve already written. > > > > However, I don't see what this has to do with running system console > > commands in a Python shell. > > Python REPL is missing the following batteries: > > * Persistent history; Dunno about that - it persists just fine on my system. Maybe it's a Windows problem? On all my Windows systems, I just use IDLE instead of the default REPL and have done with it. > * Syntax highlighting; Not usually something I need from a REPL. That's a feature for an editor. > * Clear separation (using, for example, different colors) > between input, output and errors; Input is marked with a prompt (">>>" or "..."). Errors are just another form of output. > * Paging of very long output/errors. This could definitely be improved on. I don't know that this counts as "missing batteries" though, as the standard library DOES include a hook that you could use for the purpose (sys.displayhook); it's just a matter of figuring out a suitable renderer. ChrisA From rosuav at gmail.com Fri Feb 1 15:51:11 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 2 Feb 2019 07:51:11 +1100 Subject: [Python-ideas] Running Python commands from a Shell (was: Option of running shell/console commands inside the REPL) In-Reply-To: <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> Message-ID: On Sat, Feb 2, 2019 at 7:39 AM Dan Sommers <2QdxY4RzWzUUiLuE at potatochowder.com> wrote: > > On 2/1/19 2:26 AM, Jo?o Matos wrote: > > Hello, > > > > > > Consider adding the option of running shell/console commands inside the REPL. > > Something like > >>>>!dir (This might be better on python-list rather than here) > I first ran into this in the days of teletypes and dumb > terminals, where other programs let you run shell commands > from inside them. Now the shoe appears to be on the other > foot. > > So why not turn that around? ksh (since way back when) and > bash (since 2008, according to what I read somewhere online) > have "co-processes," which allow you to run a command "in > the background," and send commands and receive replies from > it. So I tried it with Python, but it didn't work: > > $ coproc P3 { python3; } > $ echo 'import sys; print(sys.version)' >&${P3[1]} > $ read v <&${P3[0]} > [the read command just waits forever] Looks like you may have a problem with output buffering. Try running "python3 -u" to tell it to run stdout/stderr unbuffered - otherwise, Python assumes that its output is going to a file and it won't matter. Alternatively, explicitly flush stdout after output, which could be done with a display hook: _old_hook = sys.displayhook def display(obj): _old_hook(obj) sys.stdout.flush() sys.displayhook = display But unless you're expecting a lot of output, it's probably easier and just as effective to simply use "-u". ChrisA From abedillon at gmail.com Fri Feb 1 15:58:43 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 14:58:43 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: [Dan Sommers] > A mailing list is not a feed... Dan, a decades and decades long fan of > mailing lists and real email clients. I'm only familiar with Gmail which keeps reply chains coherent and moves each chain to the top of my "forums" tab based on who responded last. I haven't explored the various email clients available, can you suggest one? [Dan Sommers] > Whoever posted last ends up at the bottom of the thread, so that I can > read threads from top to bottom in chronological order. Getting the > last word in shouldn't earn a spot at the top of the list. That doesn't like any closer an approximation to a merit-based solution to me. [Dan Sommers] > > 3) There are well moderated and/or cultivated subs like > > www.reddit.com/r/science where the votes end up being a good > approximation > > to merit. > Because the moderators understand the merit(s) of who is behind every +1 > vote, or because only approved voters are allowed to vote? Part of it has to do with the subject matter. the python subreddit also has, I would say, higher quality than average discussion just like the PBS Space Time YouTube channel is one of the few places on YouTube where the comments don't generally make you abandon hope for the future of humanity. A lot of it has to do with rules put in place and enforced by the moderators. They cultivate a higher quality community by promoting a higher standard of interaction. On Fri, Feb 1, 2019 at 1:34 PM Dan Sommers < 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: > On 2/1/19 1:01 PM, Abe Dillon wrote: > > [Steven D'Aprano] > > > >> This isn't Facebook or Reddit, where +1 Likes cause messages to move > >> to the top of your feed. (And thank goodness for that.) This is a > >> technical mailing list where the worth of a proposals usually depends > >> on merit, not the number of votes. > > > > Since I just (almost simultaneously with this post) suggested giving > > Reddit a try, I feel obligated to defend it a little bit. > > [...] > > > 2) You can control, to some degree, what gets to the top of your > > feed. In an email list, it's based on who posted last which seems > > hardly an improvement. > > A mailing list is not a feed. > > Whoever posted last ends up at the bottom of the thread, so that I can > read threads from top to bottom in chronological order. Getting the > last word in shouldn't earn a spot at the top of the list. > > In my email client, I do, in fact, have complete control over what gets > to the [logical] "top of the list"; in a web-based forum, I have only > what the forum allows. > > > 3) There are well moderated and/or cultivated subs like > > www.reddit.com/r/science where the votes end up being a good > approximation > > to merit. > > Because the moderators understand the merit(s) of who is behind every +1 > vote, or because only approved voters are allowed to vote? > > Dan, a decades and decades long fan of mailing lists and real email clients > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Fri Feb 1 16:04:57 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 2 Feb 2019 08:04:57 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019 at 7:59 AM Abe Dillon wrote: >> >> Whoever posted last ends up at the bottom of the thread, so that I can >> read threads from top to bottom in chronological order. Getting the >> last word in shouldn't earn a spot at the top of the list. > > > That doesn't like any closer an approximation to a merit-based solution to me. > Maybe not, but it's consistent. You can easily scan through a thread in the order it was posted. Anything that allows things to be upvoted above other things specifically encourages you to read only the most-upvoted answers. That works for Stack Overflow, since individual answers are meant to be coherent and self-contained, and have their own comments threads; it does not work for extended discussions (which is why SO specifically discourages extended discussions in comments). Got any ideas for a "merit-based" ordering? Or: got any definition of "merit" that would actually be useful to this style of discussion? ChrisA From phd at phdru.name Fri Feb 1 16:07:08 2019 From: phd at phdru.name (Oleg Broytman) Date: Fri, 1 Feb 2019 22:07:08 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: <20190201210708.vqicwrvo6xgl3tqq@phdru.name> On Sat, Feb 02, 2019 at 07:45:43AM +1100, Chris Angelico wrote: > On Sat, Feb 2, 2019 at 7:32 AM Oleg Broytman wrote: > > > > On Fri, Feb 01, 2019 at 03:12:42PM -0500, Terry Reedy wrote: > > > On 2/1/2019 1:50 PM, James Lu wrote: > > > > It???s difficult to learn anything with a body (such as a loop or a class or a function) with the built in REPL because you can???t edit lines you???ve already written. > > > > > > However, I don't see what this has to do with running system console > > > commands in a Python shell. > > > > Python REPL is missing the following batteries: > > > > * Persistent history; > > Dunno about that - it persists just fine on my system. Maybe it's a > Windows problem? On all my Windows systems, I just use IDLE instead of > the default REPL and have done with it. > > > * Syntax highlighting; > > Not usually something I need from a REPL. That's a feature for an editor. > > > * Clear separation (using, for example, different colors) > > between input, output and errors; > > Input is marked with a prompt (">>>" or "..."). Errors are just > another form of output. Yes, that the thing - it's *another* form of output. > > * Paging of very long output/errors. > > This could definitely be improved on. I don't know that this counts as > "missing batteries" though, as the standard library DOES include a > hook that you could use for the purpose (sys.displayhook); it's just a > matter of figuring out a suitable renderer. I use it, of course: https://phdru.name/Software/dotfiles/python/init.py.html The question is - does builtin REPL need more batteries? > ChrisA Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From tjreedy at udel.edu Fri Feb 1 16:15:06 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 1 Feb 2019 16:15:06 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: Message-ID: On 2/1/2019 9:24 AM, Ken Hilton wrote: > Hi, > > As a workaround/alternative, you can just do > > ? ? >>> import os > ? ? >>> os.system('dir') For repeated use within and between sessions, put 'from os import system as oss' in a startup file. Then one only needs "oss('dir')". Note that 'dir' only works on Windows; the unix equivalent is 'ls'. However this will not work in a gui IDE without special handling in the IDE. This docstring for os.system says "Execute the command in a subshell." (It should say "Execute the command in a subshell and return the exitcode.") I presume that this docstring assumes that one is running python is a system shell and that the subshell is a 'sub' of the system shell. Anyway, the subshell expects the output, in this case, a directory listing, to go to an attached system console. If one enters the above in IDLE's shell, the output does not appear in IDLE's shell. If one started IDLE in a terminal with 'python(3) -m idlelib', it goes to that terminal. Otherwise, it goes to a subshell which immediately closes and which may or may not flash on the screen. -- Terry Jan Reedy From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 1 16:15:35 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 1 Feb 2019 15:15:35 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> On 2/1/19 2:58 PM, Abe Dillon wrote: > [Dan Sommers] > >> A mailing list is not a feed... Dan, a decades and decades long fan of >> mailing lists and real email clients. > > > I'm only familiar with Gmail which keeps reply chains coherent and moves > each chain to the top of my "forums" tab based on who responded last. > I haven't explored the various email clients available, can you suggest one? I used mutt for a long time, and then claws-mail, and now thunderbird. They all met my needs, although I did give up on claws-mail when I got a hidpi display (claws-mail based on gtk2, which doesn't grok hidpi displays). Another point in favor of email clients over web pages is that there are many of them, and *you* control the display and other preferences rather than whoever wrote the forum or owns the server. > [Dan Sommers] > >> Whoever posted last ends up at the bottom of the thread, so that I can >> read threads from top to bottom in chronological order. Getting the >> last word in shouldn't earn a spot at the top of the list. > > > That doesn't like any closer an approximation to a merit-based solution to > me. Perhaps not all by itself. Many/most email clients allow individual users to "score" emails by various criteria, and then to display higher scoring messages "above" the others, or not display certain messages at all. Personally, I don't use the automated systems, but they're very comprehensive (arguably too complicated), and again, *user* adjustable. In an optimal technical discussion, opinions from users don't count for anything. The ideas stand on their own merits and research and metrics; users only serve to confirm the methodology. Dan From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 1 16:18:42 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 1 Feb 2019 15:18:42 -0600 Subject: [Python-ideas] Fwd: Re: Running Python commands from a Shell In-Reply-To: References: Message-ID: On 2/1/19 2:51 PM, Chris Angelico wrote: > On Sat, Feb 2, 2019 at 7:39 AM Dan Sommers > <2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >> >> On 2/1/19 2:26 AM, Jo?o Matos wrote: >> > Hello, >> > >> > >> > Consider adding the option of running shell/console commands inside the REPL. >> > Something like >> >>>>!dir > > (This might be better on python-list rather than here) > >> I first ran into this in the days of teletypes and dumb >> terminals, where other programs let you run shell commands >> from inside them. Now the shoe appears to be on the other >> foot. >> >> So why not turn that around? ksh (since way back when) and >> bash (since 2008, according to what I read somewhere online) >> have "co-processes," which allow you to run a command "in >> the background," and send commands and receive replies from >> it. So I tried it with Python, but it didn't work: >> >> $ coproc P3 { python3; } >> $ echo 'import sys; print(sys.version)' >&${P3[1]} >> $ read v <&${P3[0]} >> [the read command just waits forever] > > Looks like you may have a problem with output buffering. Try running > "python3 -u" to tell it to run stdout/stderr unbuffered - otherwise, > Python assumes that its output is going to a file and it won't matter. > Alternatively, explicitly flush stdout after output, which could be > done with a display hook: > > _old_hook = sys.displayhook > def display(obj): > _old_hook(obj) > sys.stdout.flush() > sys.displayhook = display > > But unless you're expecting a lot of output, it's probably easier and > just as effective to simply use "-u". I thought about the output buffering, but it fails in the same way even if I send a quit() command to the process, and I still don't see any output in the tee file. OTOH, if I use "-i," then it works. So it's probably not a simple buffering problem, but at least I have a workaround. Thanks, Dan (Sorry, Chris, for mis-sending this the first time. Sadly, my email client isn't perfect when it comes to recognizing and replying to mailing list messages.) From stefan_ml at behnel.de Fri Feb 1 16:24:41 2019 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 1 Feb 2019 22:24:41 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: James Lu schrieb am 01.02.19 um 17:40: > A lot of the traffic on this email list is people saying ?I don?t understand? or ?that?s not what I meant? or trying to re-explain. A lot of ?-1?s are really ?I don?t see the usefulness of this?. > > So I want an open discussion on: How can we communicate clearer? While I agree with others that this is a good question worth asking, I also think that it's somewhat the nature of this list that a) the topics discussed here often require a good understanding of Python and the workings of the language, b) the described use cases and ideas are often novel and therefore may not immediately ring bells in everyone's ears, and c) many topics are recurring, so people who give a quick "-1" may just be reluctant to discuss them all over again without expecting new facets to appear (which rarely happens, in fact, although there are famously PEP-ed exceptions). And, last but not least, "I don't see the usefulness of this" is a perfectly valid counter-argument, especially for a well designed language like Python. I can think of at least one programming language that was not so lucky to have enough people say this. Stefan From steve at pearwood.info Fri Feb 1 16:48:22 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 08:48:22 +1100 Subject: [Python-ideas] Running Python commands from a Shell (was: Option of running shell/console commands inside the REPL) In-Reply-To: <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> Message-ID: <20190201214822.GY1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 02:38:43PM -0600, Dan Sommers wrote: > So why not turn that around? ksh (since way back when) and > bash (since 2008, according to what I read somewhere online) > have "co-processes," which allow you to run a command "in > the background," and send commands and receive replies from > it. So I tried it with Python, but it didn't work: > > $ coproc P3 { python3; } > $ echo 'import sys; print(sys.version)' >&${P3[1]} > $ read v <&${P3[0]} > [the read command just waits forever] This is another good example of the problem James was referring to in the thread about clearer communication. Don't assume we all know what coproc does. > A pile of experiments and examples from web pages later, I > think it's Python and not me. My example, with suitable > changes to the literal in the echo command, works with sbcl > and erl, but not python3. If I start python3 as follows: What are sbcl and erl? I'm guessing you don't mean antimony pentachloride and a municipality in Austria. Possibly Steel Bank Common Lisp and Erlang? But I'm not confident about that. Does your example work with more well-known interpreted languages with interactive interpreters such as Ruby, Lua, Javascript (outside of the browser), etc? -- Steve From tjreedy at udel.edu Fri Feb 1 16:48:23 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 1 Feb 2019 16:48:23 -0500 Subject: [Python-ideas] How do ideas on this mailing list turn into features? In-Reply-To: References: Message-ID: On 2/1/2019 1:10 PM, James Lu wrote: > How do ideas on this mailing list turn into features? What is the > typical roadmap? Can this process be documented somewhere? Ultimately, one or more people write Pull Request, usually containing new tests, that passes all tests. Then a Core Developer with current commit privileges who approves (after considering opinions of others) merges the PR into the main repository. -- Terry Jan Reedy From abedillon at gmail.com Fri Feb 1 16:55:24 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 15:55:24 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: [Chris Angelico] > Maybe not, but it's consistent. You can easily scan through a thread > in the order it was posted. That's true in the case of a subreddit conversation too. I wouldn't suggest a system that doesn't let you see the whole conversation. You can order comments by post-time if you think that's relevant for whatever reason. [Chris Angelico] > Anything that allows things to be upvoted > above other things specifically encourages you to read only the > most-upvoted answers. Anything presented in a list format specifically encourages you to read only the things at the top of the list. I haven't read discussions from 2012 because they're way down the list and I only joined python-ideas recently. A voting system is simply an attempt to make sure the stuff at the top of the list is more relevant than the stuff at the bottom. [Chris Angelico] > it does not work for extended discussions (which is why SO specifically > discourages extended discussions in comments). Why not? I've seen it work many times for extended discussions just fine. [Chris Angelico] > Got any ideas for a "merit-based" ordering? Yes, a voting system. [Chris Angelico] > Or: got any definition of "merit" that would actually be useful to this > style of discussion? No. Merit is very hard to define, but again, there are subreddits with well curated discussions and in those subreddits, the voting system seems to be a decent approximation for merit. Even in less well-curated subreddits, the voting system seems to be a decent approximation to merit. I mean, the platform exists. We don't have to rely solely on theory in hypothetical land. It's kind-of like discussing whether an encyclopedia based on user-generated content could ever be useful. It's not even hard to make a subreddit. On Fri, Feb 1, 2019 at 3:06 PM Chris Angelico wrote: > On Sat, Feb 2, 2019 at 7:59 AM Abe Dillon wrote: > >> > >> Whoever posted last ends up at the bottom of the thread, so that I can > >> read threads from top to bottom in chronological order. Getting the > >> last word in shouldn't earn a spot at the top of the list. > > > > > > That doesn't like any closer an approximation to a merit-based solution > to me. > > > > Maybe not, but it's consistent. You can easily scan through a thread > in the order it was posted. Anything that allows things to be upvoted > above other things specifically encourages you to read only the > most-upvoted answers. That works for Stack Overflow, since individual > answers are meant to be coherent and self-contained, and have their > own comments threads; it does not work for extended discussions (which > is why SO specifically discourages extended discussions in comments). > > Got any ideas for a "merit-based" ordering? Or: got any definition of > "merit" that would actually be useful to this style of discussion? > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Fri Feb 1 16:57:53 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 08:57:53 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> References: <20190129223001.GA92125@cskk.homeip.net> <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> Message-ID: <20190201215752.GZ1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 02:43:49PM -0500, Eric V. Smith wrote: > On 2/1/2019 1:59 PM, Mike Miller wrote: > >Another message here reminded me that the datetime classes are not named > >DateTime like they should be.? Why not rename them, PI and E too, with > >suitable long-term deprecation period? > > Because the hassle involved in making the change, supporting both for a > long time, invalidating tons of working code, invalidating tutorials, > migrating existing pickle files, etc. isn't worth any slight gain in > consistency. Indeed. If the change was going to be done, it should have been done in Python 3.0. Since we missed the opportunity, the benefit is too small to bother until the next(!) round of breaking changes in Python 5000 (if there ever is such a major backwards-incompatible version, which there probably won't be). Consistency is a Nice To Have, not a Must Have. The only exception to that is that I wish that ``object`` would be renamed to Object. That would distinguish between Object, the base class of all types, and object, an instance of some class. In my personal opinion, being more clear about that distinction would be worth the pain in ways that (say) renaming datetime to DateTime would not be. -- Steve From boxed at killingar.net Fri Feb 1 17:07:04 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Fri, 1 Feb 2019 23:07:04 +0100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <20190201215752.GZ1834@ando.pearwood.info> References: <20190129223001.GA92125@cskk.homeip.net> <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> Message-ID: <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> > The only exception to that is that I wish that ``object`` would be > renamed to Object. That would distinguish between Object, the base class > of all types, and object, an instance of some class. In my personal > opinion, being more clear about that distinction would be worth the pain > in ways that (say) renaming datetime to DateTime would not be. Could you detail what that pain would be? To me it seems like you'd have both names for a while with deprecation warnings. Doesn't sound too painful. Especially in the datetime case which is already quite painful. / Anders From abedillon at gmail.com Fri Feb 1 17:07:53 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 16:07:53 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: [Dan Sommers] > Another point in favor of email clients over web pages is > that there are many of them, and *you* control the display > and other preferences rather than whoever wrote the forum > or owns the server. There is a tool called the Reddit Enhancement Suite or RES (and probably others) That lets you control a great deal of the display and other preferences, however; I'm not sure how that control compares to something like Thunderbird. One thing that's nice about Reddit is you can link to posts, so if you've already discussed something at length in another thread, you can simply refer to that discussion. [Dan Sommers] > In an optimal technical discussion, opinions from users > don't count for anything. The ideas stand on their own > merits and research and metrics; users only serve to > confirm the methodology. A lot can be said about how an ideal world would work. Ideally, we could define the meaning of life and good and evil and we wouldn't need this clumsy system of laws and courts to approximate the whole mess. I don't think it's that crazy to think that a voting system might approximate merit a little better than the timestamp on a post. It's not going to be perfect, but perfect shouldn't be the enemy of better. On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: > On 2/1/19 2:58 PM, Abe Dillon wrote: > > [Dan Sommers] > > > >> A mailing list is not a feed... Dan, a decades and decades long fan of > >> mailing lists and real email clients. > > > > > > I'm only familiar with Gmail which keeps reply chains coherent and moves > > each chain to the top of my "forums" tab based on who responded last. > > I haven't explored the various email clients available, can you suggest > one? > > I used mutt for a long time, and then claws-mail, and now > thunderbird. They all met my needs, although I did give > up on claws-mail when I got a hidpi display (claws-mail > based on gtk2, which doesn't grok hidpi displays). > > Another point in favor of email clients over web pages is > that there are many of them, and *you* control the display > and other preferences rather than whoever wrote the forum > or owns the server. > > > [Dan Sommers] > > > >> Whoever posted last ends up at the bottom of the thread, so that I can > >> read threads from top to bottom in chronological order. Getting the > >> last word in shouldn't earn a spot at the top of the list. > > > > > > That doesn't like any closer an approximation to a merit-based solution > to > > me. > Perhaps not all by itself. Many/most email clients allow > individual users to "score" emails by various criteria, and > then to display higher scoring messages "above" the others, > or not display certain messages at all. Personally, I don't > use the automated systems, but they're very comprehensive > (arguably too complicated), and again, *user* adjustable. > > In an optimal technical discussion, opinions from users > don't count for anything. The ideas stand on their own > merits and research and metrics; users only serve to > confirm the methodology. > > Dan > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Fri Feb 1 17:20:49 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Fri, 1 Feb 2019 23:20:49 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190201183836.GU1834@ando.pearwood.info> References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: @Steven D'Aprano 's big answer Hi, thanks for this complete answer. I might have been a bit confusing so i'll clear some details ;) I sent about 3 mails (may be 4) in this mailing list and the python dev's one. If I sent those emails it's because I felt legitimate to give my opinion, ie : I had enough knowledge to actually have an opinion and the arguments I had were (imo) relevent. In many subjects I actually have an opinion but not the knowledge to argument. That's what I was trying to express : mailing lists are kinda hard for newcomers. > That sounds pretty spammy to me. The last thing I want to see is > something (either technology or culture) encouraging people to flood the > list with a bunch of content-free "+1" or "metoo!" messages. I'm not suggesting to actually send emails. I was more refering to reddit's possibility of voting and we couldn't do it on mails. Ofc, don't send a mail to 1k people for a "+1", that's exactly what I'm saying : I'm not gonna send an email to say "I agree" full stop. > This isn't Facebook or Reddit, where +1 Likes cause messages to move to > the top of your feed. (And thank goodness for that.) This is a technical > mailing list where the worth of a proposals usually depends on merit, > not the number of votes. That's not what I was suggesting either but I get it's confusing. The votes I was talking about have no values of popularity it's just "agree", "disagree", "neutral" like we would find in "classical" forums (this is an example of what I'm talking about, french site). > But within reason, if you have something well thought out and/or > important to say, you can and should just reply to a post and say it. That's a point for mailing lists. > I'm confused. First you complain that "a lot of emails are just > explanations of what the authors meant". That's a *good* thing, surely. > This is a technical discussion list, and if a message is unclear, then > explaning what you meant should make it more clear. > And then you say "a few messages exchanged ... would correct this" but > what do you think those messages exchanged would be if not explanations > of what the authors meant? That's probably the most unclear point of my first mail ! On a forum (no matter the form), you can edit the original post. Thus, when something was unclear, false or needed an edit, the author (or others) can edit the original post. So when someone actually reads the original post, s-he doesn't have to read the 20 mails of clearing things up to have a clear idea of what's the proposal. This is a minus one for mailing lists in my opinion. Le ven. 1 f?vr. 2019 ? 19:39, Steven D'Aprano a ?crit : > On Fri, Feb 01, 2019 at 06:42:33PM +0100, Adrien Ricocotam wrote: > > I'm kinda new to those mailing lists and those are the only ones I ever > > subscribed so I'm a bit in the audience you're targeting James. > > Hi Adrien, I see that you first posted in November and haven't posted > since. > > > What I think is bad using mailing list it's the absence of votes. I'd > often > > like to just hit a "+1" button for some mails just to say to the author > I'm > > with him and I think s.he's ideas are great. > > That sounds pretty spammy to me. The last thing I want to see is > something (either technology or culture) encouraging people to flood the > list with a bunch of content-free "+1" or "metoo!" messages. > > The occasional "I agree but have nothing else to say" message is okay, > but I wouldn't want to see fifty a day. > > This isn't Facebook or Reddit, where +1 Likes cause messages to move to > the top of your feed. (And thank goodness for that.) This is a technical > mailing list where the worth of a proposals usually depends on merit, > not the number of votes. > > > > In some of the recent threads, > > some of the ideas I agreed with were just smashed by others. I couldn't > > give my two cents and the debate juste ended and I couldn't say the > author > > I was behind him.er. > > I see that the Reply button on your email client does work, so you > clearly *can* give your two cents worth (which is exactly what you are > doing now). > > And the nature of email is that you can reply to any message in your > inbox, no matter how old. You can reply to a ten year old message > provided you still have it available in a mail folder, resurrecting > the thread. > > Whether it is polite to resurrect such long-dead threads, or whether > anyone else will respond, are separate questions. > > I realise that sometimes people are busy and cannot reply immediately to > a discussion. There have been times that I have not been able to respond > to a thread until long after it has faded away naturally, and I have > *chosen* to not respond because I decided that the discussion had been > settled and I didn't care enough to restart the discussion. > > (Sometimes a discussion settles to "nobody can decide so the status quo > wins". See Nick Coghlan's blog.) > > But within reason, if you have something well thought out and/or > important to say, you can and should just reply to a post and say it. > > > > Another thing I think is not good is the absence of > > little chit-chat > > This mailing list is often too busy as it is, without encouraging > chit-chat. > > "Hi Bob, how are the wife and kids? I've been pretty good myself, > thanks for asking, but my old injury has been aching a bit. Did I > ever tell you the story about that, its quite funny. What do you > think of Trump's latest shocking comment? Did you see that hilarious > video about a cat? Did you learn the latest trick that doctors don't > want you to know? Oh, I nearly forgot, your proposal for adding GOTO > to Python and removing for-loops is an awesome idea, +1." > > > > and editing. Actually, a lot of emails are just > > explanations of what the authors meant. That's pretty spammy and a few > > messages exchanged + editing would correct this spammy thing. > > I'm confused. First you complain that "a lot of emails are just > explanations of what the authors meant". That's a *good* thing, surely. > This is a technical discussion list, and if a message is unclear, then > explaning what you meant should make it more clear. > > And then you say "a few messages exchanged ... would correct this" but > what do you think those messages exchanged would be if not explanations > of what the authors meant? > > > > In another hand, I think mailing lists are great to avoid short and > useless > > messages. There's no spammy message like "I'm ok" which could be replaced > > by just a "+1" button. > > Which does what? Send a +1 email to a thousand people? That's pretty > spammy. > > > It forces us using LBYL principle (@poke Robert) and > > it (imho) better fills the needs of such discussions. > > > > As you may have get it, I'd rather a forum like thing rather than mailing > > lists but mailings lists are great. > > Mailing lists and web forums each have their advantages and > disadvantages, but in general, I find web forums far noisier and of less > value. > > In the future this list may be migrated to Mailman 3 which includes a > more modern web-forum-like interface as well as email. > > http://docs.mailman3.org/en/latest/userguide.html > > As I understand it, there have already been a few low-volume Python > mailing lists migrated to Mailman 3, and if they end up being successful > eventually the rest will follow. > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Fri Feb 1 17:24:46 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Fri, 1 Feb 2019 23:24:46 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: A doublon ! Because I'm not answering to anyone Some don't like forums and will leave python-ideas if we switch to forums. And I completely understand why, I'm in the same case for other mailing lists. Some suggested Google Groups. This kind of tool is really interesting since we can configure it to send mails for each message. So people wanting mails have their mails and can answer and people wanting a forum still have it. But it has several drawbacks, including it's Google so for an open source project it's not ideal. I think something that hasn't been cited is the poor readability of code posted by mails. It's juste aweful to me. You may have a trick for good formating but I think that's a good point for other systems, or at least complementary systems to mails. Le ven. 1 f?vr. 2019 ? 23:20, Adrien Ricocotam a ?crit : > @Steven D'Aprano 's big answer > Hi, thanks for this complete answer. I might have been a bit confusing so > i'll clear some details ;) > > I sent about 3 mails (may be 4) in this mailing list and the python dev's > one. If I sent those emails it's because I felt legitimate to give my > opinion, ie : I had enough knowledge to actually have an opinion and the > arguments I had were (imo) relevent. In many subjects I actually have an > opinion but not the knowledge to argument. That's what I was trying to > express : mailing lists are kinda hard for newcomers. > > > That sounds pretty spammy to me. The last thing I want to see is > > something (either technology or culture) encouraging people to flood the > > list with a bunch of content-free "+1" or "metoo!" messages. > > I'm not suggesting to actually send emails. I was more refering to > reddit's possibility of voting and we couldn't do it on mails. Ofc, don't > send a mail to 1k people for a "+1", that's exactly what I'm saying : I'm > not gonna send an email to say "I agree" full stop. > > > This isn't Facebook or Reddit, where +1 Likes cause messages to move to > > the top of your feed. (And thank goodness for that.) This is a technical > > mailing list where the worth of a proposals usually depends on merit, > > not the number of votes. > > That's not what I was suggesting either but I get it's confusing. The > votes I was talking about have no values of popularity it's just "agree", > "disagree", "neutral" like we would find in "classical" forums (this > > is an example of what I'm talking about, french site). > > > But within reason, if you have something well thought out and/or > > important to say, you can and should just reply to a post and say it. > > That's a point for mailing lists. > > > I'm confused. First you complain that "a lot of emails are just > > explanations of what the authors meant". That's a *good* thing, surely. > > This is a technical discussion list, and if a message is unclear, then > > explaning what you meant should make it more clear. > > And then you say "a few messages exchanged ... would correct this" but > > what do you think those messages exchanged would be if not explanations > > of what the authors meant? > > That's probably the most unclear point of my first mail ! > On a forum (no matter the form), you can edit the original post. Thus, > when something was unclear, false or needed an edit, the author (or others) > can edit the original post. So when someone actually reads the original > post, s-he doesn't have to read the 20 mails of clearing things up to have > a clear idea of what's the proposal. This is a minus one for mailing lists > in my opinion. > > > > > Le ven. 1 f?vr. 2019 ? 19:39, Steven D'Aprano a > ?crit : > >> On Fri, Feb 01, 2019 at 06:42:33PM +0100, Adrien Ricocotam wrote: >> > I'm kinda new to those mailing lists and those are the only ones I ever >> > subscribed so I'm a bit in the audience you're targeting James. >> >> Hi Adrien, I see that you first posted in November and haven't posted >> since. >> >> > What I think is bad using mailing list it's the absence of votes. I'd >> often >> > like to just hit a "+1" button for some mails just to say to the author >> I'm >> > with him and I think s.he's ideas are great. >> >> That sounds pretty spammy to me. The last thing I want to see is >> something (either technology or culture) encouraging people to flood the >> list with a bunch of content-free "+1" or "metoo!" messages. >> >> The occasional "I agree but have nothing else to say" message is okay, >> but I wouldn't want to see fifty a day. >> >> This isn't Facebook or Reddit, where +1 Likes cause messages to move to >> the top of your feed. (And thank goodness for that.) This is a technical >> mailing list where the worth of a proposals usually depends on merit, >> not the number of votes. >> >> >> > In some of the recent threads, >> > some of the ideas I agreed with were just smashed by others. I couldn't >> > give my two cents and the debate juste ended and I couldn't say the >> author >> > I was behind him.er. >> >> I see that the Reply button on your email client does work, so you >> clearly *can* give your two cents worth (which is exactly what you are >> doing now). >> >> And the nature of email is that you can reply to any message in your >> inbox, no matter how old. You can reply to a ten year old message >> provided you still have it available in a mail folder, resurrecting >> the thread. >> >> Whether it is polite to resurrect such long-dead threads, or whether >> anyone else will respond, are separate questions. >> >> I realise that sometimes people are busy and cannot reply immediately to >> a discussion. There have been times that I have not been able to respond >> to a thread until long after it has faded away naturally, and I have >> *chosen* to not respond because I decided that the discussion had been >> settled and I didn't care enough to restart the discussion. >> >> (Sometimes a discussion settles to "nobody can decide so the status quo >> wins". See Nick Coghlan's blog.) >> >> But within reason, if you have something well thought out and/or >> important to say, you can and should just reply to a post and say it. >> >> >> > Another thing I think is not good is the absence of >> > little chit-chat >> >> This mailing list is often too busy as it is, without encouraging >> chit-chat. >> >> "Hi Bob, how are the wife and kids? I've been pretty good myself, >> thanks for asking, but my old injury has been aching a bit. Did I >> ever tell you the story about that, its quite funny. What do you >> think of Trump's latest shocking comment? Did you see that hilarious >> video about a cat? Did you learn the latest trick that doctors don't >> want you to know? Oh, I nearly forgot, your proposal for adding GOTO >> to Python and removing for-loops is an awesome idea, +1." >> >> >> > and editing. Actually, a lot of emails are just >> > explanations of what the authors meant. That's pretty spammy and a few >> > messages exchanged + editing would correct this spammy thing. >> >> I'm confused. First you complain that "a lot of emails are just >> explanations of what the authors meant". That's a *good* thing, surely. >> This is a technical discussion list, and if a message is unclear, then >> explaning what you meant should make it more clear. >> >> And then you say "a few messages exchanged ... would correct this" but >> what do you think those messages exchanged would be if not explanations >> of what the authors meant? >> >> >> > In another hand, I think mailing lists are great to avoid short and >> useless >> > messages. There's no spammy message like "I'm ok" which could be >> replaced >> > by just a "+1" button. >> >> Which does what? Send a +1 email to a thousand people? That's pretty >> spammy. >> >> > It forces us using LBYL principle (@poke Robert) and >> > it (imho) better fills the needs of such discussions. >> > >> > As you may have get it, I'd rather a forum like thing rather than >> mailing >> > lists but mailings lists are great. >> >> Mailing lists and web forums each have their advantages and >> disadvantages, but in general, I find web forums far noisier and of less >> value. >> >> In the future this list may be migrated to Mailman 3 which includes a >> more modern web-forum-like interface as well as email. >> >> http://docs.mailman3.org/en/latest/userguide.html >> >> As I understand it, there have already been a few low-volume Python >> mailing lists migrated to Mailman 3, and if they end up being successful >> eventually the rest will follow. >> >> >> -- >> Steve >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at cskk.id.au Fri Feb 1 17:25:34 2019 From: cs at cskk.id.au (Cameron Simpson) Date: Sat, 2 Feb 2019 09:25:34 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: <20190201222534.GA57273@cskk.homeip.net> On 01Feb2019 12:35, Abe Dillon wrote: >I've pitched this before but gotten little feedback (especially positive >feedback), but I think a Reddit-style forum would be a pretty vast >improvement. We could easily start a python_ideas subreddit to try it out. Bear in mind that many participants here are against forums, myself included. A mailing list comes to me, its user interface is as _I_ want it rather than a single web based interface, and it isn't a web page. My laptop collects my email constantly in the background; I can read and reply to email while offline because the messages are local and my laptop has a working mail system which queues. Email comes to me; a forum must be visited. >I know the google group presents threaded conversations, but I've run into >enough bugs trying to use that platform that I now only interact with >python-ideas via my gmail account, and threads are flattened here. The flatness of threads is a mail reader artifact. I'm no fan of the GMail web interface on a personal basis. I use mutt, and have it configured to fold up read threads and unfold threads with unread content. The point here is that with email there are many many clients and one should find one which suits your preferred interface and behaviour. With a web interface this is basicly not a choice. And IMO web browsers are terrible email readers. Some systems like discourse offer a web interface and also email. Cheers, Cameron Simpson From steve at pearwood.info Fri Feb 1 17:25:59 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 09:25:59 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: <20190201222558.GA1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 01:01:06PM -0600, Abe Dillon wrote: [...] > 2) You can control, to some degree, what gets to the top of your feed. In > an email list, it's based on who posted last which seems hardly an > improvement. In any serious, non-toy mail client you can sort your mail by any of Date, Size, Sender, Receiver, Thread or Subject line. More powerful mail clients should allow automatic filtering of messages into subfolders, hiding or muting threads, and displaying or hiding messages based on text searches. I've seen some that also allow you to add your own custom topics, like "Work", "Personal" etc. The bottom line is that email can be sorted, filtered, shuffled, sliced and diced in an almost infinite number of ways. If your email client isn't good enough, blame the tool, not the technology. [...] > > In the future this list may be migrated to Mailman 3 which includes a > > more modern web-forum-like interface as well as email. > > > > http://docs.mailman3.org/en/latest/userguide.html > > > Can you summarize what mailman3 brings to the table? The docs aren't very > clear and have a lot of preamble. The link was intended as a starting point for people to do their own research, not a finishing point. But the main things from my perspective are: - stable web URLs for archives; - better searching; - a web interface that allows posting as well as reading posts. My guess is that most people who aren't happy with email will care about the web interface, Hyperkitty. https://pypi.org/project/HyperKitty/ https://duffy.fedorapeople.org/presentations/libreplanet%202014/Hyperkitty2.pdf Demo: https://lists.stg.fedoraproject.org/archives/ -- Steve From rosuav at gmail.com Fri Feb 1 17:26:44 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 2 Feb 2019 09:26:44 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019 at 9:21 AM Adrien Ricocotam wrote: > On a forum (no matter the form), you can edit the original post. Thus, when something was unclear, false or needed an edit, the author (or others) can edit the original post. So when someone actually reads the original post, s-he doesn't have to read the 20 mails of clearing things up to have a clear idea of what's the proposal. This is a minus one for mailing lists in my opinion. > And then people wonder whether quoted text really aligns with the original post, whether "sort by post date/time" actually means what it says, and whether people have actually changed their stance while editing a post. No thank you. In accounting, git repositories, and mailing lists, you cannot edit the past - you can only post a follow-up. ChrisA From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 1 17:28:25 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 1 Feb 2019 16:28:25 -0600 Subject: [Python-ideas] Running Python commands from a Shell In-Reply-To: <20190201214822.GY1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> <20190201214822.GY1834@ando.pearwood.info> Message-ID: <714abc45-b6bd-46da-36a1-3d3673234cff@potatochowder.com> On 2/1/19 3:48 PM, Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 02:38:43PM -0600, Dan Sommers wrote: > >> So why not turn that around? ksh (since way back when) and >> bash (since 2008, according to what I read somewhere online) >> have "co-processes," which allow you to run a command "in >> the background," and send commands and receive replies from >> it. So I tried it with Python, but it didn't work: >> >> $ coproc P3 { python3; } >> $ echo 'import sys; print(sys.version)' >&${P3[1]} >> $ read v <&${P3[0]} >> [the read command just waits forever] > > This is another good example of the problem James was referring to in > the thread about clearer communication. Don't assume we all know what > coproc does. As I indicated in what you quoted, shell co-processes allow you to run a command in the background and interact with that command from your shell. >> A pile of experiments and examples from web pages later, I >> think it's Python and not me. My example, with suitable >> changes to the literal in the echo command, works with sbcl >> and erl, but not python3. If I start python3 as follows: > > What are sbcl and erl? > > I'm guessing you don't mean antimony pentachloride and a municipality in > Austria. Possibly Steel Bank Common Lisp and Erlang? But I'm not > confident about that. Yes, the Steel Bank Common Lisp and Erlang REPLs, respectively. > Does your example work with more well-known interpreted languages with > interactive interpreters such as Ruby, Lua, Javascript (outside of the > browser), etc? I don't know (I don't write software in any of those languages, and I don't have them imstalled on my computer), but adding the "-i" flag to my python3 command makes it work (thanks to ChrisA for suggesting "-u"; it was a short leap from there to "-i.") Dan From steve at pearwood.info Fri Feb 1 17:34:09 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 09:34:09 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> References: <20190129223001.GA92125@cskk.homeip.net> <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> Message-ID: <20190201223409.GB1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 11:07:04PM +0100, Anders Hovm?ller wrote: > > > The only exception to that is that I wish that ``object`` would be > > renamed to Object. That would distinguish between Object, the base class > > of all types, and object, an instance of some class. In my personal > > opinion, being more clear about that distinction would be worth the pain > > in ways that (say) renaming datetime to DateTime would not be. > > Could you detail what that pain would be? That was described in the part of my email that you deleted. Quoting Eric: Because the hassle involved in making the change, supporting both for a long time, invalidating tons of working code, invalidating tutorials, migrating existing pickle files, etc. isn't worth any slight gain in consistency. > To me it seems like you'd > have both names for a while with deprecation warnings. Doesn't sound > too painful. Especially in the datetime case which is already quite > painful. What's painful about it? - the status quo means "no change", so there is no hassle there; - we don't have to support two names; - or manage depreciation warnings; - no working code is invalidated by "not changing" the class; - no tutorials or books are invalidated; - existing pickle files continue to work; - there are no questions on forums asking "what's the difference between datetime and DateTime, which should I use?" -- Steven From steve at pearwood.info Fri Feb 1 17:46:23 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 09:46:23 +1100 Subject: [Python-ideas] Running Python commands from a Shell In-Reply-To: <714abc45-b6bd-46da-36a1-3d3673234cff@potatochowder.com> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> <20190201214822.GY1834@ando.pearwood.info> <714abc45-b6bd-46da-36a1-3d3673234cff@potatochowder.com> Message-ID: <20190201224623.GC1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 04:28:25PM -0600, Dan Sommers wrote: > On 2/1/19 3:48 PM, Steven D'Aprano wrote: > > On Fri, Feb 01, 2019 at 02:38:43PM -0600, Dan Sommers wrote: > > > >> So why not turn that around? ksh (since way back when) and > >> bash (since 2008, according to what I read somewhere online) > >> have "co-processes," which allow you to run a command "in > >> the background," and send commands and receive replies from > >> it. So I tried it with Python, but it didn't work: > >> > >> $ coproc P3 { python3; } > >> $ echo 'import sys; print(sys.version)' >&${P3[1]} > >> $ read v <&${P3[0]} > >> [the read command just waits forever] > > > > This is another good example of the problem James was referring to in > > the thread about clearer communication. Don't assume we all know what > > coproc does. > > As I indicated in what you quoted, shell co-processes allow you to run a > command in the background and interact with that command from your > shell. Okay, but what does that mean in practice? What does it require to make it work with Python? What is your expected input and output? This is a Python forum. You can assume your readers have a good level of knowledge about Python. Outside of that, you can expect to lose a significant portion of your audience if you start talking about features, practices etc that aren't supported by the Python language, stdlib and perhaps a few of the better-known third-party libraries. E.g. me, I have no idea what you mean by "interact with that command from your shell". If you're a sys admin, you might do that fifty times a day for all I know, but I've never knowingly done it. And are we supposed to know what ">&${P3[1]}" does? It looks like your cat walked over your keyboard. -- Steve From abedillon at gmail.com Fri Feb 1 17:52:47 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 16:52:47 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: [Chris Angelico] > > And then people wonder whether quoted text really aligns with the > original post, whether "sort by post date/time" actually means what it > says, and whether people have actually changed their stance while > editing a post. No thank you. In accounting, git repositories, and > mailing lists, you cannot edit the past - you can only post a > follow-up. It's common etiquette to clearly label your edits. That's why you'll see people write "EDIT: I changed X, Y, and Z due to ". Reddit can show how long ago a given post was edited (if it was at all) and commenters can flag posts that were edited in a misleading way. There's also no inherent reason a forum couldn't keep and expose the full history of edits to each post. It would be interesting if you could link to a specific edit so when some one says "I don't understand X and you weren't clear about Z" you could edit your post to clarify and link to the edit in a response saying "I edited my post to clarify. Thanks!" On Fri, Feb 1, 2019 at 4:29 PM Chris Angelico wrote: > On Sat, Feb 2, 2019 at 9:21 AM Adrien Ricocotam > wrote: > > On a forum (no matter the form), you can edit the original post. Thus, > when something was unclear, false or needed an edit, the author (or others) > can edit the original post. So when someone actually reads the original > post, s-he doesn't have to read the 20 mails of clearing things up to have > a clear idea of what's the proposal. This is a minus one for mailing lists > in my opinion. > > > > And then people wonder whether quoted text really aligns with the > original post, whether "sort by post date/time" actually means what it > says, and whether people have actually changed their stance while > editing a post. No thank you. In accounting, git repositories, and > mailing lists, you cannot edit the past - you can only post a > follow-up. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 17:59:54 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 16:59:54 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190201222558.GA1834@ando.pearwood.info> References: <20190201183836.GU1834@ando.pearwood.info> <20190201222558.GA1834@ando.pearwood.info> Message-ID: [Steven D'Aprano] > The bottom line is that email can be sorted, filtered, shuffled, sliced > and diced in an almost infinite number of ways. If your email client > isn't good enough, blame the tool, not the technology. There's no reason a forum system couldn't accommodate sorting, filtering, shuffling, slicing and dicing. It seems the only problem is the lack of tools. [Steven D'Aprano] > The link was intended as a starting point for people to do their own > research, not a finishing point. But the main things from my perspective > are: > - stable web URLs for archives; > - better searching; > - a web interface that allows posting as well as reading posts. Thanks! I followed the link and was pretty lost by about half-way through the page. This clears things up! One thing I will say is that Reddit's search functionality has been pretty useless in my experience. It would be nice to have a useful search. On Fri, Feb 1, 2019 at 4:27 PM Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 01:01:06PM -0600, Abe Dillon wrote: > > [...] > > 2) You can control, to some degree, what gets to the top of your feed. In > > an email list, it's based on who posted last which seems hardly an > > improvement. > > In any serious, non-toy mail client you can sort your mail by any of > Date, Size, Sender, Receiver, Thread or Subject line. > > More powerful mail clients should allow automatic filtering of messages > into subfolders, hiding or muting threads, and displaying or hiding > messages based on text searches. I've seen some that also allow you to > add your own custom topics, like "Work", "Personal" etc. > > The bottom line is that email can be sorted, filtered, shuffled, sliced > and diced in an almost infinite number of ways. If your email client > isn't good enough, blame the tool, not the technology. > > > [...] > > > In the future this list may be migrated to Mailman 3 which includes a > > > more modern web-forum-like interface as well as email. > > > > > > http://docs.mailman3.org/en/latest/userguide.html > > > > > > Can you summarize what mailman3 brings to the table? The docs aren't very > > clear and have a lot of preamble. > > The link was intended as a starting point for people to do their own > research, not a finishing point. But the main things from my perspective > are: > > - stable web URLs for archives; > - better searching; > - a web interface that allows posting as well as reading posts. > > > My guess is that most people who aren't happy with email will care about > the web interface, Hyperkitty. > > https://pypi.org/project/HyperKitty/ > > > https://duffy.fedorapeople.org/presentations/libreplanet%202014/Hyperkitty2.pdf > > > Demo: https://lists.stg.fedoraproject.org/archives/ > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Fri Feb 1 18:01:36 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 2 Feb 2019 10:01:36 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019 at 9:52 AM Abe Dillon wrote: > > [Chris Angelico] >> >> And then people wonder whether quoted text really aligns with the >> original post, whether "sort by post date/time" actually means what it >> says, and whether people have actually changed their stance while >> editing a post. No thank you. In accounting, git repositories, and >> mailing lists, you cannot edit the past - you can only post a >> follow-up. > > > It's common etiquette to clearly label your edits. That's why you'll see people write "EDIT: I changed X, Y, and Z due to ". Requires cooperation and discipline. You have no proof that someone didn't unintentionally (or even maliciously) change the content of the post to misrepresent someone. > Reddit can show how long ago a given post was edited (if it was at all) and commenters can flag posts that were edited in a misleading way. There's also no inherent reason a forum couldn't keep and expose the full history of edits to each post. > Sure, it's possible to keep them all. It's not easy to adequately *show* them unless someone specifically says "show me the history". > It would be interesting if you could link to a specific edit so when some one says "I don't understand X and you weren't clear about Z" you could edit your post to clarify and link to the edit in a response saying "I edited my post to clarify. Thanks!" > I've seen that. It tends to result in posts that say "I've edited my preceding post", which is just as spammy as a followup but still disrupts the conversation. Still can't see it as an advantage. Edits like that are great for something that's meant to be a lasting document. That's why a PEP can be edited, and it retains its full history. You can go back and look at everything. But the mailing list is a discussion forum, not a document showing the final state of a discussion. ChrisA From rosuav at gmail.com Fri Feb 1 18:02:23 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 2 Feb 2019 10:02:23 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <20190201222558.GA1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019 at 10:00 AM Abe Dillon wrote: > > [Steven D'Aprano] >> >> The bottom line is that email can be sorted, filtered, shuffled, sliced >> and diced in an almost infinite number of ways. If your email client >> isn't good enough, blame the tool, not the technology. > > > There's no reason a forum system couldn't accommodate sorting, filtering, shuffling, slicing and dicing. > It seems the only problem is the lack of tools. With emails, you get your choice of tools. With web forum systems, you get the forum host's choice of tools. ChrisA From boxed at killingar.net Fri Feb 1 18:06:47 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Sat, 2 Feb 2019 00:06:47 +0100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <20190201223409.GB1834@ando.pearwood.info> References: <20190129223001.GA92125@cskk.homeip.net> <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> Message-ID: <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> > - the status quo means "no change", so there is no hassle there; Not quite true. There is a constant hassle of "do I need to write datetime.datetime.now() or datetime.now()?" I solved this at work by changing all imports to follow the "from datetime import datetime" pattern and hard banning the other statically in CI. But before that people suffered for years. I have a colleague who likes to point that the future is longer than the past. It's important to keep that perspective. Also Python is still growing so there are more future users than current users. We should take this into account also. / Anders From ricocotam at gmail.com Fri Feb 1 18:15:15 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sat, 2 Feb 2019 00:15:15 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: I think the actual proposal is having a new type of list (ie : vectors) that works like numpy but for any data. Instead of a list where the user has to be sure all the data is the same type, vectors makes him-er sure it's full of the same data than can me processed using a particular function (as s-he would do with map). I think the syntax proposed is not cool, it's kinda unique in python and doesn't feel pythonic to me. A thing I thought about but I'm not satisfy is using the new matrix-multiplication operator: my_string_vector @ str.lower def compute_grad(a_student): return "you bad" my_student_vector @ compute_grad But it's a bit confusing to me. Le ven. 1 f?vr. 2019 ? 17:04, Kirill Balunov a ?crit : > > > ??, 1 ????. 2019 ?. ? 02:24, Steven D'Aprano : > >> On Thu, Jan 31, 2019 at 09:51:20AM -0800, Chris Barker via Python-ideas >> wrote: >> >> > I do a lot of numerical programming, and used to use MATLAB and now >> numpy a >> > lot. So I am very used to "vectorization" -- i.e. having operations that >> > work on a whole collection of items at once. >> [...] >> > You can imagine that for more complex expressions the "vectorized" >> approach >> > can make for much clearer and easier to parse code. Also much faster, >> which >> > is what is usually talked about, but I think the readability is the >> bigger >> > deal. >> >> Julia has special "dot" vectorize operator that looks like this: >> >> L .+ 1 # adds 1 to each item in L >> >> func.(L) # calls f on each item in L >> >> https://julialang.org/blog/2017/01/moredots >> >> The beauty of this is that you can apply it to any function or operator >> and the compiler will automatically vectorize it. The function doesn't >> have to be written to specifically support vectorization. >> >> > IMO, the beauty of vector type is that it contains homogeneous data. > Therefore, it allows you to ensure that the method is present for each > element in the vector. The first given example is what numpy is all about > and without some guarantee that L consists of homogeneous data it hardly > make sense. The second one is just `map`. So I can't catch what you are > proposing: > > 1. To make an operator form of `map`. > 2. To pull numpy into stdlib. > 3. Or something else, which is not obvious to me from the examples given. > > With kind regards, > -gdg > > >> >> > So what does this have to do with the topic at hand? >> > >> > I know that when I'm used to working with numpy and then need to do some >> > string processing or some such, I find myself missing this >> "vectorization" >> > -- if I want to do the same operation on a whole bunch of strings, why >> do I >> > need to write a loop or comprehension or map? that is: >> > >> > [s.lower() for s in a_list_of_strings] >> > >> > rather than: >> > >> > a_list_of_strings.lower() >> >> Using Julia syntax, that might become a_list_of_strings..lower(). If you >> don't like the double dot, perhaps str.lower.(a_list_of_strings) would >> be less ugly. >> >> >> >> -- >> Steven >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 18:15:17 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 17:15:17 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <20190201222558.GA1834@ando.pearwood.info> Message-ID: [Chris Angelico] > With emails, you get your choice of tools. With web forum systems, you > get the forum host's choice of tools. There are many 3rd party tools for interacting with Reddit. It's all just data behind an API. There's no reason you couldn't have a choice of tools for a forum system. The biggest difference I see is that email APIs are more standardized. Maybe we should push for an open standard for forum-style communication. On Fri, Feb 1, 2019 at 5:03 PM Chris Angelico wrote: > On Sat, Feb 2, 2019 at 10:00 AM Abe Dillon wrote: > > > > [Steven D'Aprano] > >> > >> The bottom line is that email can be sorted, filtered, shuffled, sliced > >> and diced in an almost infinite number of ways. If your email client > >> isn't good enough, blame the tool, not the technology. > > > > > > There's no reason a forum system couldn't accommodate sorting, > filtering, shuffling, slicing and dicing. > > It seems the only problem is the lack of tools. > > With emails, you get your choice of tools. With web forum systems, you > get the forum host's choice of tools. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.eliziario at gmail.com Fri Feb 1 18:26:08 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 1 Feb 2019 21:26:08 -0200 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <20190201222558.GA1834@ando.pearwood.info> Message-ID: Email is based on open standards with multiple implementations, most of them open source, that you can run basically wherever you want. Reddit is a product from a company, with a privately controlled API, and that may not even be here tomorrow, and it is not based on open standards. What happens if Reddit goes bankrupt tomorrow? And let's not forget that mailing lists have a small barrier to entry. Moving this list to a forum would likely become an "eternal september" kind of event. Simple is good. Email is simple. Em sex, 1 de fev de 2019 ?s 21:17, Abe Dillon escreveu: > [Chris Angelico] > >> With emails, you get your choice of tools. With web forum systems, you >> get the forum host's choice of tools. > > > There are many 3rd party tools for interacting with Reddit. > It's all just data behind an API. There's no reason you couldn't have a > choice of tools for a forum system. > The biggest difference I see is that email APIs are more standardized. > Maybe we should push for an open standard for forum-style communication. > > > On Fri, Feb 1, 2019 at 5:03 PM Chris Angelico wrote: > >> On Sat, Feb 2, 2019 at 10:00 AM Abe Dillon wrote: >> > >> > [Steven D'Aprano] >> >> >> >> The bottom line is that email can be sorted, filtered, shuffled, sliced >> >> and diced in an almost infinite number of ways. If your email client >> >> isn't good enough, blame the tool, not the technology. >> > >> > >> > There's no reason a forum system couldn't accommodate sorting, >> filtering, shuffling, slicing and dicing. >> > It seems the only problem is the lack of tools. >> >> With emails, you get your choice of tools. With web forum systems, you >> get the forum host's choice of tools. >> >> ChrisA >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 18:36:09 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 17:36:09 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: [Chris Angelico] > > > It's common etiquette to clearly label your edits. That's why you'll see > people write "EDIT: I changed X, Y, and Z due to ". > Requires cooperation and discipline. Any form of civil communication requires cooperation and discipline. [Chris Angelico] > You have no proof that someone didn't unintentionally (or even > maliciously) change the content of the > post to misrepresent someone. A) As I said in the post you're quoting, it's not necessarily true that you have no proof. B) I don't know of any forum system that allows you to misrepresent some one else. Editing your own post maliciously can only be used to misrepresent what you said. Even then, if your edit history is available, any attempt to do so can be called out. [Chris Angelico] > > Reddit can show how long ago a given post was edited (if it was at all) > and commenters can flag posts that were edited in a misleading way. There's > also no inherent reason a forum couldn't keep and expose the full history > of edits to each post. > > > Sure, it's possible to keep them all. It's not easy to adequately > *show* them unless someone specifically says "show me the history". That's a matter of interface design. It may be just as easy as un-collapsing responses. Hopefully, if the community isn't full of liars and jerks, I don't see why the edit history would need to be super easy to explore. [Chris Angelico] > > It would be interesting if you could link to a specific edit so when > some one says "I don't understand X and you weren't clear about Z" you > could edit your post to clarify and link to the edit in a response saying > "I edited my post to clarify. Thanks!" > > > I've seen that. It tends to result in posts that say "I've edited my > preceding post", which is just as spammy as a followup but still > disrupts the conversation. Just saying "I've edited my preceding post" is not the same as being able to link to the edit so that the person can clearly see exactly how you addressed their question. [Chris Angelico] > Still can't see it as an advantage. The advantage is that other people don't have to dig down into a conversation to get all the clarifications and explanations that would otherwise be missing in your original post. [Chris Angelico] > Edits like that are great for something that's meant to be a lasting > document. That's why a PEP can be edited, and it retains its full > history. You can go back and look at everything. But the mailing list > is a discussion forum, not a document showing the final state of a > discussion. I don't see how it would hurt discussion to have both. You can keep the: "X doesn't make any sense and I don't get Y" comment *and* the response referencing where those points are addressed *and* the make the fully edited version of the OP visible *and* allow anyone to review the edit history. None of those things are mutually exclusive. On Fri, Feb 1, 2019 at 5:02 PM Chris Angelico wrote: > On Sat, Feb 2, 2019 at 9:52 AM Abe Dillon wrote: > > > > [Chris Angelico] > >> > >> And then people wonder whether quoted text really aligns with the > >> original post, whether "sort by post date/time" actually means what it > >> says, and whether people have actually changed their stance while > >> editing a post. No thank you. In accounting, git repositories, and > >> mailing lists, you cannot edit the past - you can only post a > >> follow-up. > > > > > > It's common etiquette to clearly label your edits. That's why you'll see > people write "EDIT: I changed X, Y, and Z due to ". > > Requires cooperation and discipline. You have no proof that someone > didn't unintentionally (or even maliciously) change the content of the > post to misrepresent someone. > > > Reddit can show how long ago a given post was edited (if it was at all) > and commenters can flag posts that were edited in a misleading way. There's > also no inherent reason a forum couldn't keep and expose the full history > of edits to each post. > > > > Sure, it's possible to keep them all. It's not easy to adequately > *show* them unless someone specifically says "show me the history". > > > It would be interesting if you could link to a specific edit so when > some one says "I don't understand X and you weren't clear about Z" you > could edit your post to clarify and link to the edit in a response saying > "I edited my post to clarify. Thanks!" > > > > I've seen that. It tends to result in posts that say "I've edited my > preceding post", which is just as spammy as a followup but still > disrupts the conversation. Still can't see it as an advantage. > > Edits like that are great for something that's meant to be a lasting > document. That's why a PEP can be edited, and it retains its full > history. You can go back and look at everything. But the mailing list > is a discussion forum, not a document showing the final state of a > discussion. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 19:03:02 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 18:03:02 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <20190201222558.GA1834@ando.pearwood.info> Message-ID: [Marcos Eliziario] > Email is based on open standards with multiple implementations, most of > them open source, that you can run basically wherever you want. > Reddit is a product from a company, with a privately controlled API, and > that may not even be here tomorrow, and it is not based on open standards. > What happens if Reddit goes bankrupt tomorrow? That's a good point. I suggested Reddit because it has a pretty extensive feature list and is fairly simple to set-up and try. Maybe we could make /r/python_thoughts instead of /r/python_ideas to denote the separation (i.e. nothing posted on /r/python_thoughts will be automatically shared on the python-ideas email list or vice-versa) or maybe there's some forum software based on open standards that has a similar feature set? Or maybe there are no open standards for internet forums, in which case, how would one go about advocating for such a thing? [Marcos Eliziario] > Simple is good. Email is simple. Simple *can* be good, but it *can* also get in the way of fruitful conversation... On Fri, Feb 1, 2019 at 5:26 PM Marcos Eliziario wrote: > Email is based on open standards with multiple implementations, most of > them open source, that you can run basically wherever you want. > Reddit is a product from a company, with a privately controlled API, and > that may not even be here tomorrow, and it is not based on open standards. > What happens if Reddit goes bankrupt tomorrow? > > And let's not forget that mailing lists have a small barrier to entry. > Moving this list to a forum would likely become an "eternal september" kind > of event. > > Simple is good. Email is simple. > > > > Em sex, 1 de fev de 2019 ?s 21:17, Abe Dillon > escreveu: > >> [Chris Angelico] >> >>> With emails, you get your choice of tools. With web forum systems, you >>> get the forum host's choice of tools. >> >> >> There are many 3rd party tools for interacting with Reddit. >> It's all just data behind an API. There's no reason you couldn't have a >> choice of tools for a forum system. >> The biggest difference I see is that email APIs are more standardized. >> Maybe we should push for an open standard for forum-style communication. >> >> >> On Fri, Feb 1, 2019 at 5:03 PM Chris Angelico wrote: >> >>> On Sat, Feb 2, 2019 at 10:00 AM Abe Dillon wrote: >>> > >>> > [Steven D'Aprano] >>> >> >>> >> The bottom line is that email can be sorted, filtered, shuffled, >>> sliced >>> >> and diced in an almost infinite number of ways. If your email client >>> >> isn't good enough, blame the tool, not the technology. >>> > >>> > >>> > There's no reason a forum system couldn't accommodate sorting, >>> filtering, shuffling, slicing and dicing. >>> > It seems the only problem is the lack of tools. >>> >>> With emails, you get your choice of tools. With web forum systems, you >>> get the forum host's choice of tools. >>> >>> ChrisA >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Marcos Elizi?rio Santos > mobile/whatsapp/telegram: +55(21) 9-8027-0156 > skype: marcos.eliziario at gmail.com > linked-in : https://www.linkedin.com/in/eliziario/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Fri Feb 1 19:19:35 2019 From: mertz at gnosis.cx (David Mertz) Date: Fri, 1 Feb 2019 19:19:35 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: I have absolutely no interest in any system that arranges comments in anything but related thread and chronological order. I DO NOT want any rating or evaluation of comments of any kind other than my own evaluation based on reading them. Well, also in reading the informed opinions of other readers. I would find it useless if not actively counterproductive to follow any system where such ratings of comments existed. There is one property that every system invented to supercede email have in common. They are all dramatically worse in almost every way. On Fri, Feb 1, 2019, 5:09 PM Abe Dillon [Dan Sommers] > >> Another point in favor of email clients over web pages is >> that there are many of them, and *you* control the display >> and other preferences rather than whoever wrote the forum >> or owns the server. > > > There is a tool called the Reddit Enhancement Suite or RES (and probably > others) > That lets you control a great deal of the display and other preferences, > however; I'm not > sure how that control compares to something like Thunderbird. > > One thing that's nice about Reddit is you can link to posts, so if you've > already discussed something at length in another thread, > you can simply refer to that discussion. > > [Dan Sommers] > >> In an optimal technical discussion, opinions from users >> don't count for anything. The ideas stand on their own >> merits and research and metrics; users only serve to >> confirm the methodology. > > > A lot can be said about how an ideal world would work. Ideally, we could > define the meaning of life and good and evil and we wouldn't need this > clumsy system of laws and courts to approximate the whole mess. > > I don't think it's that crazy to think that a voting system might > approximate merit a little better than the timestamp on a post. > It's not going to be perfect, but perfect shouldn't be the enemy of better. > > On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < > 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: > >> On 2/1/19 2:58 PM, Abe Dillon wrote: >> > [Dan Sommers] >> > >> >> A mailing list is not a feed... Dan, a decades and decades long fan of >> >> mailing lists and real email clients. >> > >> > >> > I'm only familiar with Gmail which keeps reply chains coherent and moves >> > each chain to the top of my "forums" tab based on who responded last. >> > I haven't explored the various email clients available, can you suggest >> one? >> >> I used mutt for a long time, and then claws-mail, and now >> thunderbird. They all met my needs, although I did give >> up on claws-mail when I got a hidpi display (claws-mail >> based on gtk2, which doesn't grok hidpi displays). >> >> Another point in favor of email clients over web pages is >> that there are many of them, and *you* control the display >> and other preferences rather than whoever wrote the forum >> or owns the server. >> >> > [Dan Sommers] >> > >> >> Whoever posted last ends up at the bottom of the thread, so that I can >> >> read threads from top to bottom in chronological order. Getting the >> >> last word in shouldn't earn a spot at the top of the list. >> > >> > >> > That doesn't like any closer an approximation to a merit-based solution >> to >> > me. >> Perhaps not all by itself. Many/most email clients allow >> individual users to "score" emails by various criteria, and >> then to display higher scoring messages "above" the others, >> or not display certain messages at all. Personally, I don't >> use the automated systems, but they're very comprehensive >> (arguably too complicated), and again, *user* adjustable. >> >> In an optimal technical discussion, opinions from users >> don't count for anything. The ideas stand on their own >> merits and research and metrics; users only serve to >> confirm the methodology. >> >> Dan >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Fri Feb 1 19:21:29 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 02 Feb 2019 13:21:29 +1300 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: <5C54E289.3050604@canterbury.ac.nz> Adrien Ricocotam wrote: > On a forum (no matter the form), you can edit the original post. Thus, > when something was unclear, false or needed an edit, the author (or > others) can edit the original post. So when someone actually reads the > original post, s-he doesn't have to read the 20 mails of clearing things > up to have a clear idea of what's the proposal. On the other hand, you have to skip over the 20 replies confusingly talking about things in the original post that are no longer there. Being able to edit posts has both advantages and disadvantages. -- Greg From greg.ewing at canterbury.ac.nz Fri Feb 1 19:24:42 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 02 Feb 2019 13:24:42 +1300 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: <5C54E34A.3010901@canterbury.ac.nz> Adrien Ricocotam wrote: > I think something that hasn't been cited is the poor readability of code > posted by mails. It's juste aweful to me. You may have a trick for good > formating but I think that's a good point for other systems, or at least > complementary systems to mails. In my experience, the only "tricks" required are to post in plain text and use only spaces for indentation. -- Greg From marcos.eliziario at gmail.com Fri Feb 1 19:25:13 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 1 Feb 2019 22:25:13 -0200 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: Simple tools, free-format are always more conductive to the free exchange of ideas. Let's not forget that a huge chunk of our current science and math was built with scientists collaborating over physical mail delivered by sailboats across the channel, train and even horse carriages. Em sex, 1 de fev de 2019 ?s 22:20, David Mertz escreveu: > I have absolutely no interest in any system that arranges comments in > anything but related thread and chronological order. I DO NOT want any > rating or evaluation of comments of any kind other than my own evaluation > based on reading them. Well, also in reading the informed opinions of other > readers. > > I would find it useless if not actively counterproductive to follow any > system where such ratings of comments existed. > > There is one property that every system invented to supercede email have > in common. They are all dramatically worse in almost every way. > > On Fri, Feb 1, 2019, 5:09 PM Abe Dillon >> [Dan Sommers] >> >>> Another point in favor of email clients over web pages is >>> that there are many of them, and *you* control the display >>> and other preferences rather than whoever wrote the forum >>> or owns the server. >> >> >> There is a tool called the Reddit Enhancement Suite or RES (and probably >> others) >> That lets you control a great deal of the display and other preferences, >> however; I'm not >> sure how that control compares to something like Thunderbird. >> >> One thing that's nice about Reddit is you can link to posts, so if you've >> already discussed something at length in another thread, >> you can simply refer to that discussion. >> >> [Dan Sommers] >> >>> In an optimal technical discussion, opinions from users >>> don't count for anything. The ideas stand on their own >>> merits and research and metrics; users only serve to >>> confirm the methodology. >> >> >> A lot can be said about how an ideal world would work. Ideally, we could >> define the meaning of life and good and evil and we wouldn't need this >> clumsy system of laws and courts to approximate the whole mess. >> >> I don't think it's that crazy to think that a voting system might >> approximate merit a little better than the timestamp on a post. >> It's not going to be perfect, but perfect shouldn't be the enemy of >> better. >> >> On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < >> 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >> >>> On 2/1/19 2:58 PM, Abe Dillon wrote: >>> > [Dan Sommers] >>> > >>> >> A mailing list is not a feed... Dan, a decades and decades long fan of >>> >> mailing lists and real email clients. >>> > >>> > >>> > I'm only familiar with Gmail which keeps reply chains coherent and >>> moves >>> > each chain to the top of my "forums" tab based on who responded last. >>> > I haven't explored the various email clients available, can you >>> suggest one? >>> >>> I used mutt for a long time, and then claws-mail, and now >>> thunderbird. They all met my needs, although I did give >>> up on claws-mail when I got a hidpi display (claws-mail >>> based on gtk2, which doesn't grok hidpi displays). >>> >>> Another point in favor of email clients over web pages is >>> that there are many of them, and *you* control the display >>> and other preferences rather than whoever wrote the forum >>> or owns the server. >>> >>> > [Dan Sommers] >>> > >>> >> Whoever posted last ends up at the bottom of the thread, so that I can >>> >> read threads from top to bottom in chronological order. Getting the >>> >> last word in shouldn't earn a spot at the top of the list. >>> > >>> > >>> > That doesn't like any closer an approximation to a merit-based >>> solution to >>> > me. >>> Perhaps not all by itself. Many/most email clients allow >>> individual users to "score" emails by various criteria, and >>> then to display higher scoring messages "above" the others, >>> or not display certain messages at all. Personally, I don't >>> use the automated systems, but they're very comprehensive >>> (arguably too complicated), and again, *user* adjustable. >>> >>> In an optimal technical discussion, opinions from users >>> don't count for anything. The ideas stand on their own >>> merits and research and metrics; users only serve to >>> confirm the methodology. >>> >>> Dan >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 19:29:55 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 18:29:55 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: [David Mertz] > I have absolutely no interest in any system that arranges comments in > anything but related thread and chronological order. I DO NOT want any > rating or evaluation of comments of any kind other than my own evaluation > based on reading them. Well, also in reading the informed opinions of other > readers. I would find it useless if not actively counterproductive to follow any > system where such ratings of comments existed. Then just sort by chronological order. On Fri, Feb 1, 2019 at 6:19 PM David Mertz wrote: > I have absolutely no interest in any system that arranges comments in > anything but related thread and chronological order. I DO NOT want any > rating or evaluation of comments of any kind other than my own evaluation > based on reading them. Well, also in reading the informed opinions of other > readers. > > I would find it useless if not actively counterproductive to follow any > system where such ratings of comments existed. > > There is one property that every system invented to supercede email have > in common. They are all dramatically worse in almost every way. > > On Fri, Feb 1, 2019, 5:09 PM Abe Dillon >> [Dan Sommers] >> >>> Another point in favor of email clients over web pages is >>> that there are many of them, and *you* control the display >>> and other preferences rather than whoever wrote the forum >>> or owns the server. >> >> >> There is a tool called the Reddit Enhancement Suite or RES (and probably >> others) >> That lets you control a great deal of the display and other preferences, >> however; I'm not >> sure how that control compares to something like Thunderbird. >> >> One thing that's nice about Reddit is you can link to posts, so if you've >> already discussed something at length in another thread, >> you can simply refer to that discussion. >> >> [Dan Sommers] >> >>> In an optimal technical discussion, opinions from users >>> don't count for anything. The ideas stand on their own >>> merits and research and metrics; users only serve to >>> confirm the methodology. >> >> >> A lot can be said about how an ideal world would work. Ideally, we could >> define the meaning of life and good and evil and we wouldn't need this >> clumsy system of laws and courts to approximate the whole mess. >> >> I don't think it's that crazy to think that a voting system might >> approximate merit a little better than the timestamp on a post. >> It's not going to be perfect, but perfect shouldn't be the enemy of >> better. >> >> On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < >> 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >> >>> On 2/1/19 2:58 PM, Abe Dillon wrote: >>> > [Dan Sommers] >>> > >>> >> A mailing list is not a feed... Dan, a decades and decades long fan of >>> >> mailing lists and real email clients. >>> > >>> > >>> > I'm only familiar with Gmail which keeps reply chains coherent and >>> moves >>> > each chain to the top of my "forums" tab based on who responded last. >>> > I haven't explored the various email clients available, can you >>> suggest one? >>> >>> I used mutt for a long time, and then claws-mail, and now >>> thunderbird. They all met my needs, although I did give >>> up on claws-mail when I got a hidpi display (claws-mail >>> based on gtk2, which doesn't grok hidpi displays). >>> >>> Another point in favor of email clients over web pages is >>> that there are many of them, and *you* control the display >>> and other preferences rather than whoever wrote the forum >>> or owns the server. >>> >>> > [Dan Sommers] >>> > >>> >> Whoever posted last ends up at the bottom of the thread, so that I can >>> >> read threads from top to bottom in chronological order. Getting the >>> >> last word in shouldn't earn a spot at the top of the list. >>> > >>> > >>> > That doesn't like any closer an approximation to a merit-based >>> solution to >>> > me. >>> Perhaps not all by itself. Many/most email clients allow >>> individual users to "score" emails by various criteria, and >>> then to display higher scoring messages "above" the others, >>> or not display certain messages at all. Personally, I don't >>> use the automated systems, but they're very comprehensive >>> (arguably too complicated), and again, *user* adjustable. >>> >>> In an optimal technical discussion, opinions from users >>> don't count for anything. The ideas stand on their own >>> merits and research and metrics; users only serve to >>> confirm the methodology. >>> >>> Dan >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 1 19:33:38 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 1 Feb 2019 18:33:38 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: On 2/1/19 4:07 PM, Abe Dillon wrote: > One thing that's nice about Reddit is you can link to posts, so if you've > already discussed something at length in another thread, > you can simply refer to that discussion. Mailman keeps an archive of all email sent to the python mailing list, and the individual messages have unique links. Usually, referring to a discussion by the subject of the email messages and some sort of date range is enough for someone to find the relevant discussions in the archive. I agree that it's not painless. After a while, I end up with my own "archive" in my email client (or in my email server), and I can reply to old messages as needed. This is also not painless. From mertz at gnosis.cx Fri Feb 1 19:36:54 2019 From: mertz at gnosis.cx (David Mertz) Date: Fri, 1 Feb 2019 19:36:54 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: To be clear. Most of what I don't want is a system where OTHER people are relying on ratings rather than careful reading. I want to communicate on changes where posts cannot be "voted up" or edited, etc. Mind you, I do know this other than this sort of discussion had other needs. GitHub issues are very useful. Occasionally I'll even go back and edit a prior comment rather than add another. But there I'm trying to make the issue genuinely correctly describe the issue at hand. Stack Overflow or Stack Exchange are very useful for finding technical answers. Voting up best response there is extremely useful. I do not want python-ideas to resemble those. It is simply not the appropriate kind of discussion. On Fri, Feb 1, 2019, 7:30 PM Abe Dillon [David Mertz] > >> I have absolutely no interest in any system that arranges comments in >> anything but related thread and chronological order. I DO NOT want any >> rating or evaluation of comments of any kind other than my own evaluation >> based on reading them. Well, also in reading the informed opinions of other >> readers. > > > > I would find it useless if not actively counterproductive to follow any >> system where such ratings of comments existed. > > > Then just sort by chronological order. > > On Fri, Feb 1, 2019 at 6:19 PM David Mertz wrote: > >> I have absolutely no interest in any system that arranges comments in >> anything but related thread and chronological order. I DO NOT want any >> rating or evaluation of comments of any kind other than my own evaluation >> based on reading them. Well, also in reading the informed opinions of other >> readers. >> >> I would find it useless if not actively counterproductive to follow any >> system where such ratings of comments existed. >> >> There is one property that every system invented to supercede email have >> in common. They are all dramatically worse in almost every way. >> >> On Fri, Feb 1, 2019, 5:09 PM Abe Dillon > >>> [Dan Sommers] >>> >>>> Another point in favor of email clients over web pages is >>>> that there are many of them, and *you* control the display >>>> and other preferences rather than whoever wrote the forum >>>> or owns the server. >>> >>> >>> There is a tool called the Reddit Enhancement Suite or RES (and probably >>> others) >>> That lets you control a great deal of the display and other preferences, >>> however; I'm not >>> sure how that control compares to something like Thunderbird. >>> >>> One thing that's nice about Reddit is you can link to posts, so if >>> you've already discussed something at length in another thread, >>> you can simply refer to that discussion. >>> >>> [Dan Sommers] >>> >>>> In an optimal technical discussion, opinions from users >>>> don't count for anything. The ideas stand on their own >>>> merits and research and metrics; users only serve to >>>> confirm the methodology. >>> >>> >>> A lot can be said about how an ideal world would work. Ideally, we could >>> define the meaning of life and good and evil and we wouldn't need this >>> clumsy system of laws and courts to approximate the whole mess. >>> >>> I don't think it's that crazy to think that a voting system might >>> approximate merit a little better than the timestamp on a post. >>> It's not going to be perfect, but perfect shouldn't be the enemy of >>> better. >>> >>> On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < >>> 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >>> >>>> On 2/1/19 2:58 PM, Abe Dillon wrote: >>>> > [Dan Sommers] >>>> > >>>> >> A mailing list is not a feed... Dan, a decades and decades long fan >>>> of >>>> >> mailing lists and real email clients. >>>> > >>>> > >>>> > I'm only familiar with Gmail which keeps reply chains coherent and >>>> moves >>>> > each chain to the top of my "forums" tab based on who responded last. >>>> > I haven't explored the various email clients available, can you >>>> suggest one? >>>> >>>> I used mutt for a long time, and then claws-mail, and now >>>> thunderbird. They all met my needs, although I did give >>>> up on claws-mail when I got a hidpi display (claws-mail >>>> based on gtk2, which doesn't grok hidpi displays). >>>> >>>> Another point in favor of email clients over web pages is >>>> that there are many of them, and *you* control the display >>>> and other preferences rather than whoever wrote the forum >>>> or owns the server. >>>> >>>> > [Dan Sommers] >>>> > >>>> >> Whoever posted last ends up at the bottom of the thread, so that I >>>> can >>>> >> read threads from top to bottom in chronological order. Getting the >>>> >> last word in shouldn't earn a spot at the top of the list. >>>> > >>>> > >>>> > That doesn't like any closer an approximation to a merit-based >>>> solution to >>>> > me. >>>> Perhaps not all by itself. Many/most email clients allow >>>> individual users to "score" emails by various criteria, and >>>> then to display higher scoring messages "above" the others, >>>> or not display certain messages at all. Personally, I don't >>>> use the automated systems, but they're very comprehensive >>>> (arguably too complicated), and again, *user* adjustable. >>>> >>>> In an optimal technical discussion, opinions from users >>>> don't count for anything. The ideas stand on their own >>>> merits and research and metrics; users only serve to >>>> confirm the methodology. >>>> >>>> Dan >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.eliziario at gmail.com Fri Feb 1 19:38:32 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 1 Feb 2019 22:38:32 -0200 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: Typical technical discussion in threaded discussion foruns --First Post -- First Level -- First level with an interesting idea (let's do B?) -- 2nd level discussing some potential issues with B -- 2nd level workaround for said issues, namely, making sure D -- 2nd level more discussion -- 2nd level add nausean -- 3rd replied by mistake last poster, not parent thread -- 3rd some are answering here now -- 2nd another guy answering ad nausean here -- 2nd unrelated thoughts -- 2nd discussion continues on the parent level, but some answers are buried on the level below "ad nausean -- a consensus is found! -- Yeah, let's do B, but taking care of D -- bla bla bla .... .... -- Hey, what if we did B? -- all over again......... Em sex, 1 de fev de 2019 ?s 22:30, Abe Dillon escreveu: > [David Mertz] > >> I have absolutely no interest in any system that arranges comments in >> anything but related thread and chronological order. I DO NOT want any >> rating or evaluation of comments of any kind other than my own evaluation >> based on reading them. Well, also in reading the informed opinions of other >> readers. > > > > I would find it useless if not actively counterproductive to follow any >> system where such ratings of comments existed. > > > Then just sort by chronological order. > > On Fri, Feb 1, 2019 at 6:19 PM David Mertz wrote: > >> I have absolutely no interest in any system that arranges comments in >> anything but related thread and chronological order. I DO NOT want any >> rating or evaluation of comments of any kind other than my own evaluation >> based on reading them. Well, also in reading the informed opinions of other >> readers. >> >> I would find it useless if not actively counterproductive to follow any >> system where such ratings of comments existed. >> >> There is one property that every system invented to supercede email have >> in common. They are all dramatically worse in almost every way. >> >> On Fri, Feb 1, 2019, 5:09 PM Abe Dillon > >>> [Dan Sommers] >>> >>>> Another point in favor of email clients over web pages is >>>> that there are many of them, and *you* control the display >>>> and other preferences rather than whoever wrote the forum >>>> or owns the server. >>> >>> >>> There is a tool called the Reddit Enhancement Suite or RES (and probably >>> others) >>> That lets you control a great deal of the display and other preferences, >>> however; I'm not >>> sure how that control compares to something like Thunderbird. >>> >>> One thing that's nice about Reddit is you can link to posts, so if >>> you've already discussed something at length in another thread, >>> you can simply refer to that discussion. >>> >>> [Dan Sommers] >>> >>>> In an optimal technical discussion, opinions from users >>>> don't count for anything. The ideas stand on their own >>>> merits and research and metrics; users only serve to >>>> confirm the methodology. >>> >>> >>> A lot can be said about how an ideal world would work. Ideally, we could >>> define the meaning of life and good and evil and we wouldn't need this >>> clumsy system of laws and courts to approximate the whole mess. >>> >>> I don't think it's that crazy to think that a voting system might >>> approximate merit a little better than the timestamp on a post. >>> It's not going to be perfect, but perfect shouldn't be the enemy of >>> better. >>> >>> On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < >>> 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >>> >>>> On 2/1/19 2:58 PM, Abe Dillon wrote: >>>> > [Dan Sommers] >>>> > >>>> >> A mailing list is not a feed... Dan, a decades and decades long fan >>>> of >>>> >> mailing lists and real email clients. >>>> > >>>> > >>>> > I'm only familiar with Gmail which keeps reply chains coherent and >>>> moves >>>> > each chain to the top of my "forums" tab based on who responded last. >>>> > I haven't explored the various email clients available, can you >>>> suggest one? >>>> >>>> I used mutt for a long time, and then claws-mail, and now >>>> thunderbird. They all met my needs, although I did give >>>> up on claws-mail when I got a hidpi display (claws-mail >>>> based on gtk2, which doesn't grok hidpi displays). >>>> >>>> Another point in favor of email clients over web pages is >>>> that there are many of them, and *you* control the display >>>> and other preferences rather than whoever wrote the forum >>>> or owns the server. >>>> >>>> > [Dan Sommers] >>>> > >>>> >> Whoever posted last ends up at the bottom of the thread, so that I >>>> can >>>> >> read threads from top to bottom in chronological order. Getting the >>>> >> last word in shouldn't earn a spot at the top of the list. >>>> > >>>> > >>>> > That doesn't like any closer an approximation to a merit-based >>>> solution to >>>> > me. >>>> Perhaps not all by itself. Many/most email clients allow >>>> individual users to "score" emails by various criteria, and >>>> then to display higher scoring messages "above" the others, >>>> or not display certain messages at all. Personally, I don't >>>> use the automated systems, but they're very comprehensive >>>> (arguably too complicated), and again, *user* adjustable. >>>> >>>> In an optimal technical discussion, opinions from users >>>> don't count for anything. The ideas stand on their own >>>> merits and research and metrics; users only serve to >>>> confirm the methodology. >>>> >>>> Dan >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 19:57:56 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 18:57:56 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: [David Mertz] > To be clear. Most of what I don't want is a system where OTHER people are > relying on ratings rather than careful reading. In my experience, there's nothing you can do to make other people read anything carefully. Plus, many of the counterpoints have been "I have a lot more freedom in filtering and organizing emails with my email client", so I fear your dreams of forcing everybody to read everything will never be realized. As I've pointed out before, putting things in chronological order doesn't force people to read anything, it just favors new over old. I haven't read any of the discussions before 2016 (save a few). [David Mertz] > Mind you, I do know this other than this sort of discussion had other > needs. GitHub issues are very useful. Occasionally I'll even go back and > edit a prior comment rather than add another. But there I'm trying to make > the issue genuinely correctly describe the issue at hand. The ability to edit in discussions is useful for the exact same reason. I have to say. I've frequented Reddit for years and never had to deal with a disingenuous edit. I think that fear is a bit overblown. [David Mertz] > Stack Overflow or Stack Exchange are very useful for finding technical > answers. Voting up best response there is extremely useful. > I do not want python-ideas to resemble those. It is simply not the > appropriate kind of discussion. I find it very useful for discussion. I don't know why people keep declaring it's no good for discussion without explaining why. On Fri, Feb 1, 2019 at 6:37 PM David Mertz wrote: > To be clear. Most of what I don't want is a system where OTHER people are > relying on ratings rather than careful reading. I want to communicate on > changes where posts cannot be "voted up" or edited, etc. > > Mind you, I do know this other than this sort of discussion had other > needs. GitHub issues are very useful. Occasionally I'll even go back and > edit a prior comment rather than add another. But there I'm trying to make > the issue genuinely correctly describe the issue at hand. > > Stack Overflow or Stack Exchange are very useful for finding technical > answers. Voting up best response there is extremely useful. > > I do not want python-ideas to resemble those. It is simply not the > appropriate kind of discussion. > > On Fri, Feb 1, 2019, 7:30 PM Abe Dillon >> [David Mertz] >> >>> I have absolutely no interest in any system that arranges comments in >>> anything but related thread and chronological order. I DO NOT want any >>> rating or evaluation of comments of any kind other than my own evaluation >>> based on reading them. Well, also in reading the informed opinions of other >>> readers. >> >> >> >> I would find it useless if not actively counterproductive to follow any >>> system where such ratings of comments existed. >> >> >> Then just sort by chronological order. >> >> On Fri, Feb 1, 2019 at 6:19 PM David Mertz wrote: >> >>> I have absolutely no interest in any system that arranges comments in >>> anything but related thread and chronological order. I DO NOT want any >>> rating or evaluation of comments of any kind other than my own evaluation >>> based on reading them. Well, also in reading the informed opinions of other >>> readers. >>> >>> I would find it useless if not actively counterproductive to follow any >>> system where such ratings of comments existed. >>> >>> There is one property that every system invented to supercede email have >>> in common. They are all dramatically worse in almost every way. >>> >>> On Fri, Feb 1, 2019, 5:09 PM Abe Dillon >> >>>> [Dan Sommers] >>>> >>>>> Another point in favor of email clients over web pages is >>>>> that there are many of them, and *you* control the display >>>>> and other preferences rather than whoever wrote the forum >>>>> or owns the server. >>>> >>>> >>>> There is a tool called the Reddit Enhancement Suite or RES (and >>>> probably others) >>>> That lets you control a great deal of the display and other >>>> preferences, however; I'm not >>>> sure how that control compares to something like Thunderbird. >>>> >>>> One thing that's nice about Reddit is you can link to posts, so if >>>> you've already discussed something at length in another thread, >>>> you can simply refer to that discussion. >>>> >>>> [Dan Sommers] >>>> >>>>> In an optimal technical discussion, opinions from users >>>>> don't count for anything. The ideas stand on their own >>>>> merits and research and metrics; users only serve to >>>>> confirm the methodology. >>>> >>>> >>>> A lot can be said about how an ideal world would work. Ideally, we >>>> could define the meaning of life and good and evil and we wouldn't need >>>> this clumsy system of laws and courts to approximate the whole mess. >>>> >>>> I don't think it's that crazy to think that a voting system might >>>> approximate merit a little better than the timestamp on a post. >>>> It's not going to be perfect, but perfect shouldn't be the enemy of >>>> better. >>>> >>>> On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < >>>> 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >>>> >>>>> On 2/1/19 2:58 PM, Abe Dillon wrote: >>>>> > [Dan Sommers] >>>>> > >>>>> >> A mailing list is not a feed... Dan, a decades and decades long fan >>>>> of >>>>> >> mailing lists and real email clients. >>>>> > >>>>> > >>>>> > I'm only familiar with Gmail which keeps reply chains coherent and >>>>> moves >>>>> > each chain to the top of my "forums" tab based on who responded last. >>>>> > I haven't explored the various email clients available, can you >>>>> suggest one? >>>>> >>>>> I used mutt for a long time, and then claws-mail, and now >>>>> thunderbird. They all met my needs, although I did give >>>>> up on claws-mail when I got a hidpi display (claws-mail >>>>> based on gtk2, which doesn't grok hidpi displays). >>>>> >>>>> Another point in favor of email clients over web pages is >>>>> that there are many of them, and *you* control the display >>>>> and other preferences rather than whoever wrote the forum >>>>> or owns the server. >>>>> >>>>> > [Dan Sommers] >>>>> > >>>>> >> Whoever posted last ends up at the bottom of the thread, so that I >>>>> can >>>>> >> read threads from top to bottom in chronological order. Getting the >>>>> >> last word in shouldn't earn a spot at the top of the list. >>>>> > >>>>> > >>>>> > That doesn't like any closer an approximation to a merit-based >>>>> solution to >>>>> > me. >>>>> Perhaps not all by itself. Many/most email clients allow >>>>> individual users to "score" emails by various criteria, and >>>>> then to display higher scoring messages "above" the others, >>>>> or not display certain messages at all. Personally, I don't >>>>> use the automated systems, but they're very comprehensive >>>>> (arguably too complicated), and again, *user* adjustable. >>>>> >>>>> In an optimal technical discussion, opinions from users >>>>> don't count for anything. The ideas stand on their own >>>>> merits and research and metrics; users only serve to >>>>> confirm the methodology. >>>>> >>>>> Dan >>>>> _______________________________________________ >>>>> Python-ideas mailing list >>>>> Python-ideas at python.org >>>>> https://mail.python.org/mailman/listinfo/python-ideas >>>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Fri Feb 1 19:59:25 2019 From: mertz at gnosis.cx (David Mertz) Date: Fri, 1 Feb 2019 19:59:25 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: On Fri, Feb 1, 2019, 6:16 PM Adrien Ricocotam A thing I thought about but I'm not satisfy is using the new > matrix-multiplication operator: > > my_string_vector @ str.lower > > def compute_grad(a_student): > return "you bad" > my_student_vector @ compute_grad > This is certainly doable. But why would it be better than: map(str.lower, my_string_vector) map(compute_grad, my_student_vector) These latter seem obvious, clear, and familiar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Fri Feb 1 20:01:58 2019 From: abedillon at gmail.com (Abe Dillon) Date: Fri, 1 Feb 2019 19:01:58 -0600 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: [Marcos Eliziario] > Typical technical discussion in threaded discussion foruns > --First Post > -- First Level > -- First level with an interesting idea (let's do B?) > -- 2nd level discussing some potential issues with B > -- 2nd level workaround for said issues, namely, making sure D > -- 2nd level more discussion > -- 2nd level add nausean > -- 3rd replied by mistake last poster, not parent thread > -- 3rd some are answering here now > -- 2nd another guy answering ad nausean here > -- 2nd unrelated thoughts > -- 2nd discussion continues on the parent level, but some answers are > buried on the level below "ad nausean > -- a consensus is found! > -- Yeah, let's do B, but taking care of D > -- bla bla bla > .... > .... > -- Hey, what if we did B? > -- all over again......... Is this intended to make forums look better or worse than the typical Python-ideas thread. My experience has been: -- First Post -- Counterpoint A -- I'm -1 on this -- Counterpoint A -- Counterpoint A -- Counterpoint B -- Counterpoint A -- I'm -1 on this -- Counterpoint A ... On Fri, Feb 1, 2019 at 6:38 PM Marcos Eliziario wrote: > Typical technical discussion in threaded discussion foruns > --First Post > -- First Level > -- First level with an interesting idea (let's do B?) > -- 2nd level discussing some potential issues with B > -- 2nd level workaround for said issues, namely, making sure D > -- 2nd level more discussion > -- 2nd level add nausean > -- 3rd replied by mistake last poster, not parent thread > -- 3rd some are answering here now > -- 2nd another guy answering ad nausean here > -- 2nd unrelated thoughts > -- 2nd discussion continues on the parent level, but some answers are > buried on the level below "ad nausean > -- a consensus is found! > -- Yeah, let's do B, but taking care of D > -- bla bla bla > .... > .... > -- Hey, what if we did B? > -- all over again......... > > > > Em sex, 1 de fev de 2019 ?s 22:30, Abe Dillon > escreveu: > >> [David Mertz] >> >>> I have absolutely no interest in any system that arranges comments in >>> anything but related thread and chronological order. I DO NOT want any >>> rating or evaluation of comments of any kind other than my own evaluation >>> based on reading them. Well, also in reading the informed opinions of other >>> readers. >> >> >> >> I would find it useless if not actively counterproductive to follow any >>> system where such ratings of comments existed. >> >> >> Then just sort by chronological order. >> >> On Fri, Feb 1, 2019 at 6:19 PM David Mertz wrote: >> >>> I have absolutely no interest in any system that arranges comments in >>> anything but related thread and chronological order. I DO NOT want any >>> rating or evaluation of comments of any kind other than my own evaluation >>> based on reading them. Well, also in reading the informed opinions of other >>> readers. >>> >>> I would find it useless if not actively counterproductive to follow any >>> system where such ratings of comments existed. >>> >>> There is one property that every system invented to supercede email have >>> in common. They are all dramatically worse in almost every way. >>> >>> On Fri, Feb 1, 2019, 5:09 PM Abe Dillon >> >>>> [Dan Sommers] >>>> >>>>> Another point in favor of email clients over web pages is >>>>> that there are many of them, and *you* control the display >>>>> and other preferences rather than whoever wrote the forum >>>>> or owns the server. >>>> >>>> >>>> There is a tool called the Reddit Enhancement Suite or RES (and >>>> probably others) >>>> That lets you control a great deal of the display and other >>>> preferences, however; I'm not >>>> sure how that control compares to something like Thunderbird. >>>> >>>> One thing that's nice about Reddit is you can link to posts, so if >>>> you've already discussed something at length in another thread, >>>> you can simply refer to that discussion. >>>> >>>> [Dan Sommers] >>>> >>>>> In an optimal technical discussion, opinions from users >>>>> don't count for anything. The ideas stand on their own >>>>> merits and research and metrics; users only serve to >>>>> confirm the methodology. >>>> >>>> >>>> A lot can be said about how an ideal world would work. Ideally, we >>>> could define the meaning of life and good and evil and we wouldn't need >>>> this clumsy system of laws and courts to approximate the whole mess. >>>> >>>> I don't think it's that crazy to think that a voting system might >>>> approximate merit a little better than the timestamp on a post. >>>> It's not going to be perfect, but perfect shouldn't be the enemy of >>>> better. >>>> >>>> On Fri, Feb 1, 2019 at 3:17 PM Dan Sommers < >>>> 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: >>>> >>>>> On 2/1/19 2:58 PM, Abe Dillon wrote: >>>>> > [Dan Sommers] >>>>> > >>>>> >> A mailing list is not a feed... Dan, a decades and decades long fan >>>>> of >>>>> >> mailing lists and real email clients. >>>>> > >>>>> > >>>>> > I'm only familiar with Gmail which keeps reply chains coherent and >>>>> moves >>>>> > each chain to the top of my "forums" tab based on who responded last. >>>>> > I haven't explored the various email clients available, can you >>>>> suggest one? >>>>> >>>>> I used mutt for a long time, and then claws-mail, and now >>>>> thunderbird. They all met my needs, although I did give >>>>> up on claws-mail when I got a hidpi display (claws-mail >>>>> based on gtk2, which doesn't grok hidpi displays). >>>>> >>>>> Another point in favor of email clients over web pages is >>>>> that there are many of them, and *you* control the display >>>>> and other preferences rather than whoever wrote the forum >>>>> or owns the server. >>>>> >>>>> > [Dan Sommers] >>>>> > >>>>> >> Whoever posted last ends up at the bottom of the thread, so that I >>>>> can >>>>> >> read threads from top to bottom in chronological order. Getting the >>>>> >> last word in shouldn't earn a spot at the top of the list. >>>>> > >>>>> > >>>>> > That doesn't like any closer an approximation to a merit-based >>>>> solution to >>>>> > me. >>>>> Perhaps not all by itself. Many/most email clients allow >>>>> individual users to "score" emails by various criteria, and >>>>> then to display higher scoring messages "above" the others, >>>>> or not display certain messages at all. Personally, I don't >>>>> use the automated systems, but they're very comprehensive >>>>> (arguably too complicated), and again, *user* adjustable. >>>>> >>>>> In an optimal technical discussion, opinions from users >>>>> don't count for anything. The ideas stand on their own >>>>> merits and research and metrics; users only serve to >>>>> confirm the methodology. >>>>> >>>>> Dan >>>>> _______________________________________________ >>>>> Python-ideas mailing list >>>>> Python-ideas at python.org >>>>> https://mail.python.org/mailman/listinfo/python-ideas >>>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Marcos Elizi?rio Santos > mobile/whatsapp/telegram: +55(21) 9-8027-0156 > skype: marcos.eliziario at gmail.com > linked-in : https://www.linkedin.com/in/eliziario/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benrudiak at gmail.com Fri Feb 1 20:10:13 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Fri, 1 Feb 2019 17:10:13 -0800 Subject: [Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS In-Reply-To: References: <20190129223001.GA92125@cskk.homeip.net> Message-ID: On Fri, Feb 1, 2019 at 11:24 AM Abe Dillon wrote: > "why not make everything default to 'final' and put 'var' or something > in-front of the few outliers?". > If it happens, it'll be another example of mainstream languages adopting ideas from functional programming. I love it when that happens, I just wish it didn't take decades. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eryksun at gmail.com Fri Feb 1 20:21:47 2019 From: eryksun at gmail.com (eryk sun) Date: Fri, 1 Feb 2019 19:21:47 -0600 Subject: [Python-ideas] Running Python commands from a Shell In-Reply-To: <20190201224623.GC1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> <20190201214822.GY1834@ando.pearwood.info> <714abc45-b6bd-46da-36a1-3d3673234cff@potatochowder.com> <20190201224623.GC1834@ando.pearwood.info> Message-ID: On 2/1/19, Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 04:28:25PM -0600, Dan Sommers wrote: > >> As I indicated in what you quoted, shell co-processes allow you to run a >> command in the background and interact with that command from your >> shell. > > Okay, but what does that mean in practice? What does it require to make > it work with Python? What is your expected input and output? bash coproc runs a process in the background with stdin and stdout redirected to pipes. The file descriptors for our end of the pipes are available in an array with the given name (e.g. P3). The default array name is COPROC. As soon as "pipe" is mentioned, anyone familiar with the REPL's behavior with pipes should know that making this work will require the -i command-line option to force interactive mode. Otherwise stdout will be fully buffered. For example: $ coproc P3 { python3 -qi 2>&1; } [1] 16923 $ echo 'import sys; print(sys.version)' >&${P3[1]} $ read -t 1 <&${P3[0]} && echo $REPLY >>> 3.6.7 (default, Oct 22 2018, 11:32:17) $ read -t 1 <&${P3[0]} && echo $REPLY [GCC 8.2.0] $ read -t 1 <&${P3[0]} && echo $REPLY $ echo 'sys.exit(42)' >&${P3[1]} $ [1]+ Exit 42 coproc P3 { python3 -qi 2>&1; } > And are we supposed to know what ">&${P3[1]}" does? It looks like your > cat walked over your keyboard. It redirects the command's standard output (>) to the file descriptor (&) in index 1 of the P3 array (${P3[1]}), which is our end of the pipe that's connected to stdin of the co-process. From tjreedy at udel.edu Fri Feb 1 20:40:22 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 1 Feb 2019 20:40:22 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190201203121.yffztjtoxdbczmnc@phdru.name> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: On 2/1/2019 3:31 PM, Oleg Broytman wrote: > Python REPL is missing the following batteries: That is why, on Windows, I nearly always use IDLE. > * Persistent history; IDLE's Shell history persists across restarts (which are not available is the standard shell). I cannot remember wanting history saved between IDLE sessions. I also cannot remember seeing a request for this feature. If I want a sequence of commands saved, I copy them into an editor window and save in a named file. > * Syntax highlighting; IDLE does this. > * Clear separation (using, for example, different colors) > between input, output and errors; IDLE does this. > * Paging of very long output/errors. Help output *is* paged in the standard shell. For comparison with IDLE, for issue 35855, I tried out help(tkinter) in standard Python on both Windows and Mac. For the most part, I found the pagers to be somewhat obnoxious and deficient*. Except for one thing that I want to fix, paging up an down a window with the standard PageUp and PageDown keys, as in IDLE, is easier and better. And it is not limited * Windows Console holds a maximum of 9999 characters, with the default being 300, at least for Command Prompt. The less pager, at least on Mac, when invoked by help when running Python in Terminal, displays the paged output in a separate window. When less is exited, the window closes and the paged output *disappears*. You left out what I think is a very important 'battery': * Works with Python statements instead of physical lines of text. As I discussed elsewhere, this includes editing entire multiline statements before submitting and storing and retrieving complete statements to and from the history list. Here is another: * Clicking on a traceback item can open the file in an editor at the indicated line. -- Terry Jan Reedy From eryksun at gmail.com Fri Feb 1 21:43:53 2019 From: eryksun at gmail.com (eryk sun) Date: Fri, 1 Feb 2019 20:43:53 -0600 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: On 2/1/19, Terry Reedy wrote: > On 2/1/2019 3:31 PM, Oleg Broytman wrote: > >> Python REPL is missing the following batteries: >> * Persistent history; Python's built-in REPL relies on the readline module for history. In Windows you'll need to install pyreadline, an implementation that uses the Windows console API via ctypes. Out of the box, Python uses the the built-in line editing and history that's provided by the Windows console host (conhost.exe). There's an undocumented function to read this history (as used by doskey.exe), but there's no function to load lines into it. I suppose it could be replayed manually in a loop that calls WriteConsoleInputW and ReadConsoleW. > * Windows Console holds a maximum of 9999 characters, 9999 lines, not characters. From steve at pearwood.info Fri Feb 1 21:44:25 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 13:44:25 +1100 Subject: [Python-ideas] Running Python commands from a Shell In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> <20190201214822.GY1834@ando.pearwood.info> <714abc45-b6bd-46da-36a1-3d3673234cff@potatochowder.com> <20190201224623.GC1834@ando.pearwood.info> Message-ID: <20190202024425.GD1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 07:21:47PM -0600, eryk sun wrote: > bash coproc runs a process in the background with stdin and stdout > redirected to pipes. The file descriptors for our end of the pipes are > available in an array with the given name (e.g. P3). The default array > name is COPROC. Thanks for the explanation. > As soon as "pipe" is mentioned, anyone familiar with the REPL's > behavior with pipes should know that making this work will require the > -i command-line option to force interactive mode. Otherwise stdout > will be fully buffered. For example: [...] I wonder... could Python automatically detect when it is connected to pipes and switch buffering off? > > And are we supposed to know what ">&${P3[1]}" does? It looks like your > > cat walked over your keyboard. > > It redirects the command's standard output (>) to the file descriptor > (&) in index 1 of the P3 array (${P3[1]}), which is our end of the > pipe that's connected to stdin of the co-process. And this is why I don't program in bash :-) -- Steven From steve at pearwood.info Fri Feb 1 21:50:00 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 13:50:00 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: Message-ID: <20190202024959.GE1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 04:15:06PM -0500, Terry Reedy wrote: > For repeated use within and between sessions, put 'from os import system > as oss' in a startup file. Then one only needs "oss('dir')". Note that > 'dir' only works on Windows; the unix equivalent is 'ls'. Actually, on some Unix/Linux systems, ``dir`` is either an alias to ``ls``, or a similar but separate executable: [steve at ando ~]$ which dir /usr/bin/dir (TIL that dir can be a seperate executable... I was convinced it was only an alias until I tried it just now.) -- Steve From eryksun at gmail.com Fri Feb 1 22:02:56 2019 From: eryksun at gmail.com (eryk sun) Date: Fri, 1 Feb 2019 21:02:56 -0600 Subject: [Python-ideas] Running Python commands from a Shell In-Reply-To: <20190202024425.GD1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <3feb296d-e129-f5c7-6aef-9113a3c30405@potatochowder.com> <20190201214822.GY1834@ando.pearwood.info> <714abc45-b6bd-46da-36a1-3d3673234cff@potatochowder.com> <20190201224623.GC1834@ando.pearwood.info> <20190202024425.GD1834@ando.pearwood.info> Message-ID: On 2/1/19, Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 07:21:47PM -0600, eryk sun wrote: > >> As soon as "pipe" is mentioned, anyone familiar with the REPL's >> behavior with pipes should know that making this work will require the >> -i command-line option to force interactive mode. Otherwise stdout >> will be fully buffered. For example: > [...] > > I wonder... could Python automatically detect when it is connected to > pipes and switch buffering off? In most cases we want full buffering when standard I/O is a pipe or disk file. It's more efficient to read/write large chunks from/to the OS. In another message I saw -u mentioned to disable buffering. But that's not sufficient. We need -i to force running the built-in REPL over a pipe, and optionally -q to quiet the initial banner message. From steve at pearwood.info Fri Feb 1 22:10:06 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 14:10:06 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190201203121.yffztjtoxdbczmnc@phdru.name> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: <20190202031006.GF1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 09:31:21PM +0100, Oleg Broytman wrote: > Python REPL is missing the following batteries: > > * Persistent history; On Linux/Unix systems, that has been available for about 18+ years, since the rlcompleter module was introduced in Python 2.0: https://docs.python.org/release/2.0/lib/module-rlcompleter.html It's been automatically enabled for more than six years: https://hg.python.org/cpython/rev/d5ef330bac50 Windows is another story. > * Syntax highlighting; bpython provides syntax highlighting in the REPL, but I've never seen the point. In an editor, perhaps, but why bother in the REPL? https://bpython-interpreter.org/ So does DreamPie: http://www.dreampie.org/ > * Clear separation (using, for example, different colors) > between input, output and errors; Input always starts with a prompt; exception tracebacks always start with the line "Traceback..."; other errors are generally not programmatically distinguishable from non-errors. One could modify the displayhook and excepthook to deal with the usual cases, but colour codes are not just platform-specific but console- specific. https://docs.python.org/3.5/library/sys.html#sys.displayhook https://docs.python.org/3.5/library/sys.html#sys.excepthook > * Paging of very long output/errors. I don't know how I feel about that. Now that Python shrinks long tracebacks filled with identical lines, I'm not sure that this is so important or desirable. >>> import sys >>> sys.setrecursionlimit(30) >>> def spam(): ... spam() ... >>> spam() Traceback (most recent call last): File "", line 1, in File "", line 2, in spam File "", line 2, in spam File "", line 2, in spam [Previous line repeated 26 more times] RecursionError: maximum recursion depth exceeded -- Steve From greg.ewing at canterbury.ac.nz Fri Feb 1 22:57:08 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 02 Feb 2019 16:57:08 +1300 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: <5C551514.9010404@canterbury.ac.nz> Abe Dillon wrote: > As I've pointed out before, putting things in > chronological order doesn't force people to read anything, it just > favors new over old. Um, what? People talking about chronological order here mean *oldest to newest*, not the other way around. This is not meant to "favour" anything, it's so that you get to read the discussion in the order it was written. If that's what you want to do. -- Greg From steve at pearwood.info Fri Feb 1 23:32:55 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 15:32:55 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: <20190202043254.GG1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 07:02:30PM +0300, Kirill Balunov wrote: > ??, 1 ????. 2019 ?. ? 02:24, Steven D'Aprano : [...] > > Julia has special "dot" vectorize operator that looks like this: > > > > L .+ 1 # adds 1 to each item in L > > > > func.(L) # calls f on each item in L > > > > https://julialang.org/blog/2017/01/moredots > > > > The beauty of this is that you can apply it to any function or operator > > and the compiler will automatically vectorize it. The function doesn't > > have to be written to specifically support vectorization. > > > > > IMO, the beauty of vector type is that it contains homogeneous data. I didn't say anything about a vector type. "Vectorization" does not mean "vector type". Please read the link I posted, it talks about what Julia does and how it works. There are two relevant meanings for vectorization here: https://en.wikipedia.org/wiki/Vectorization - a style of computer programming where operations are applied to whole arrays instead of individual elements - a compiler optimization that transforms loops to vector operations Given that none of my examples involved writing loops by hand, I could only be talking about the first. The link I posted has examples which should be fairly clear even if you don't know Julia well. > Therefore, it allows you to ensure that the method is present for each > element in the vector. The first given example is what numpy is all about > and without some guarantee that L consists of homogeneous data it hardly > make sense. Of course it makes sense. Even numpy supports inhomogeneous data: py> a = np.array([1, 'spam']) py> a array(['1', 'spam'], dtype='|S4') Inhomogeneous data may rule out some optimizations, but that hardly means that it "doesn't make sense" to use it. Again, if you read the link I posted, they make it clear that Julia can vectorize code which supports any type: "Our function f accepts any x type" I don't know Julia well enough to tell whether it supports inhomogeneous arrays. My experiments suggest that it forces all the elements to a single type. But that's not really the point: you can call the function f on an array of one type (say, Spam), then call it again on an array of another type (say, Eggs). So long as the function supports both Spam and Eggs types, it will just work, without having to re-write your array handling code. > The second one is just `map`. So I can't catch what you are > proposing: I'm not proposing anything, I'm drawing people's attention to something another language does to solve an annoyance that Chris has. If someone else likes that solution and wishes to make a concrete proposal for Python, we can consider it. Otherwise it is just food for thought. It may or may not lead anywhere. > 1. To make an operator form of `map`. > 2. To pull numpy into stdlib. I cannot imagine how you got that conclusion from anything I said. I was talking about syntax for vectorization, and didn't mention numpy once. I didn't mention django or beautifulsoup either. I hope that you didn't conclude that I wanted to pull them into the stdlib too. -- Steven From steve at pearwood.info Fri Feb 1 23:37:36 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 15:37:36 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190202031006.GF1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202031006.GF1834@ando.pearwood.info> Message-ID: <20190202043735.GH1834@ando.pearwood.info> Sorry, I was not as clear as I ought to have been: On Sat, Feb 02, 2019 at 02:10:06PM +1100, Steven D'Aprano wrote: > > * Clear separation (using, for example, different colors) > > between input, output and errors; > > Input always starts with a prompt; exception tracebacks always start > with the line "Traceback..."; other errors are generally not > programmatically distinguishable from non-errors. By which I mean, if a script or module reports an error by just printing a message to the screen: print("sorry, an error occurred") sort of thing. Obviously the interpreter cannot guess which messages represent errors in that sense and which are non-error output. (Of course, a script could format its own error messages, say by using terminal-specific colour codes.) -- Steve From python at mrabarnett.plus.com Sat Feb 2 00:10:14 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sat, 2 Feb 2019 05:10:14 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202043254.GG1834@ando.pearwood.info> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> Message-ID: On 2019-02-02 04:32, Steven D'Aprano wrote: [snip] > > Of course it makes sense. Even numpy supports inhomogeneous data: > [snip] "inhomogeneous"? Who came up with that? "in-" is a negative prefix in Latin words, but "homogeneous" comes from Greek, where the negative prefix is "a-" (or "an-" before a vowel). I'd go with either "heterogeneous" or "non-homogeneous". From robertve92 at gmail.com Sat Feb 2 01:19:34 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Sat, 2 Feb 2019 07:19:34 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: * I didn't have time to read the whole convo' yet * I think linking to a tutorial on "how to use a mailing list" that shows some examples on popular email client like Gmail on android or Mail in iOS would be something really helpful to beginners. When they subscribe, a bot would send that link alongside a nice welcoming message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Feb 2 01:45:38 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 17:45:38 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: <20190202064537.GI1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 12:35:15PM -0600, Abe Dillon wrote: > I've pitched this before but gotten little feedback (especially positive > feedback), but I think a Reddit-style forum would be a pretty vast > improvement. We could easily start a python_ideas subreddit to try it out. I don't think you need anyone's permission to do so. Provided you don't try to pass it off as in any way official or blessed by the PSF (not to be confused with the Python Secret Underground which most emphatically does not exist) you might as well try it and see what happens. But some reasons why I am luke-warm on the idea: - I can have as many email identities as I like; I can only have one Reddit identity at a time. If I want to keep my Reddit persona seperate from my Python persona, I need to create multiple accounts (possibly violating the terms of service?) and remember to log out of one and into the other. - Too difficult (impossible?) to keep local human-readable copies of either the discussion thread, or even your own posts. - I have to explicitly go to the site to see what is happening, rather than have the posts automatically arrive in my inbox. - Ads. - Reddit's new web UI. (How long before the "old.reddit..." URLs stop working?) -- Steven From tritium-list at sdamon.com Sat Feb 2 02:06:56 2019 From: tritium-list at sdamon.com (Alex Walters) Date: Sat, 2 Feb 2019 02:06:56 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> Message-ID: <0e2201d4bac5$e28b7160$a7a25420$@sdamon.com> > -----Original Message----- > From: Python-ideas list=sdamon.com at python.org> On Behalf Of MRAB > Sent: Saturday, February 2, 2019 12:10 AM > To: python-ideas at python.org > Subject: Re: [Python-ideas] Vectorization [was Re: Add list.join() please] > > On 2019-02-02 04:32, Steven D'Aprano wrote: > [snip] > > > > Of course it makes sense. Even numpy supports inhomogeneous data: > > > [snip] > > "inhomogeneous"? Who came up with that? > > "in-" is a negative prefix in Latin words, but "homogeneous" > comes from Greek, where the negative prefix is "a-" (or "an-" before a > vowel). I'd go with either "heterogeneous" or "non-homogeneous". > "Television" as a word must annoy you :) I mentally replaced "inhomogeneous" with "heterogeneous" > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From steve at pearwood.info Sat Feb 2 03:41:24 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 19:41:24 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> Message-ID: <20190202084124.GJ1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovm?ller wrote: > > > - the status quo means "no change", so there is no hassle there; > > Not quite true. There is a constant hassle of "do I need to write > datetime.datetime.now() or datetime.now()?" My point was that there is no hassle from *making a change* if you don't actually make a change. (There may, or may not, be other, unrelated hassles.) Besides, I'm not seeing that this is any worse than any other import. Do I call spam.Eggs.make() or Eggs.make()? If you don't remember what you imported, the names don't make much difference. I accept that datetime.datetime reads a bit funny and is a bit annoying. If we had the keys to the time machine and could go back a decade to version 3.0, or even further back to 1.5 or whenever the datetime module was first created, it would be nice to change it so that the class was DateTime. But changing it *now* is not free, it has real, serious costs which are probably greater than the benefit gained. > I solved this at work by changing all imports to follow the "from > datetime import datetime" pattern and hard banning the other > statically in CI. But before that people suffered for years. Oh how they must have suffered *wink* I'm surprised that you don't do this: from datetime import datetime as DateTime > I have a colleague who likes to point that the future is longer than > the past. It's important to keep that perspective. Actually, no, on average, the projected lifespan of technologies, companies and cultural memes is about the same as their current age. It might last less, or it might last more, but the statistical expectation is about the same as the current age. So on average, "the future" is about the same as "the past". Python has been around not quite 30 years now, so we can expect that it will probably last another 30 years. But chances are not good that it will be around in 300 years. -- Steve From steve at pearwood.info Sat Feb 2 03:58:35 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 19:58:35 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> Message-ID: <20190202085835.GK1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 05:10:14AM +0000, MRAB wrote: > On 2019-02-02 04:32, Steven D'Aprano wrote: > [snip] > > > >Of course it makes sense. Even numpy supports inhomogeneous data: > > > [snip] > > "inhomogeneous"? Who came up with that? I don't know, but it has been used since at least the early 1920s https://english.stackexchange.com/questions/194906/heterogeneous-vs-inhomogeneous and the Oxford dictionary describes "inhomogenity" as being used from the late 19th century. So my guess is, probably people who were more familiar with Latin and Greek than we are. There are many words that are derived from both Latin and Greek. There's no rule that says that because a word was derived from Greek, we must use Greek grammatical forms for it. We are speaking English, not Greek, and in English, we can negate words using the "in" prefix. -- Steven From steve at pearwood.info Sat Feb 2 04:02:43 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 20:02:43 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <0e2201d4bac5$e28b7160$a7a25420$@sdamon.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <0e2201d4bac5$e28b7160$a7a25420$@sdamon.com> Message-ID: <20190202090242.GL1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 02:06:56AM -0500, Alex Walters wrote: > "Television" as a word must annoy you :) I mentally replaced > "inhomogeneous" with "heterogeneous" They don't mean the same thing. https://english.stackexchange.com/questions/194906/heterogeneous-vs-inhomogeneous -- Steven From kirillbalunov at gmail.com Sat Feb 2 04:22:10 2019 From: kirillbalunov at gmail.com (Kirill Balunov) Date: Sat, 2 Feb 2019 12:22:10 +0300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202043254.GG1834@ando.pearwood.info> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> Message-ID: ??, 2 ????. 2019 ?. ? 07:33, Steven D'Aprano : > > I didn't say anything about a vector type. > > I agree you did not say. But since you started a new thread from the one where the vector type was a little discussed, it seemed to me that it is appropriate to mention it here. Sorry about that. > > Therefore, it allows you to ensure that the method is present for each > > element in the vector. The first given example is what numpy is all about > > and without some guarantee that L consists of homogeneous data it hardly > > make sense. > > Of course it makes sense. Even numpy supports inhomogeneous data: > > py> a = np.array([1, 'spam']) > py> a > array(['1', 'spam'], > dtype='|S4') > > Yes, numpy, at some degree, supports heterogeneous arrays. But not in the way you brought it. Your example just shows homogeneous array of type `'|S4'`. In the same way as `np.array([1, 1.234])` will be homogeneous. Of course you can say - np.array([1, 'spam'], dtype='object'), but in this case it will also be homogeneous array, but of type `object`. > Inhomogeneous data may rule out some optimizations, but that hardly > means that it "doesn't make sense" to use it. > I did not say that it "doesn't make sense". I only said that you should be lucky to call `..method()` on collections of heterogeneous data. And therefore, usually this kind of operations imply that you are working with a "homogeneous data". Unfortunately, built-in containers cannot provide such a guarantee without self-checking. Therefore, in my opinion that at the moment such an operator is not needed. With kind regards, -gdg -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Sat Feb 2 04:54:16 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sat, 2 Feb 2019 10:54:16 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> Message-ID: @D?aprano I think you?re misleading by what I said, sorry for not being crystal clear. I just read the link on Julia (which I didn?t do) and I get what you mean now and it?s not quite different from what I said. I proposed introducing a new type : ? vector ? A few steps have been made in Python for typing and I think the next step is having typed collections. Keeping with nothing checked is better imo. So if we take this next step, we?ll get a vector type with *not-guaranteed* homogeneous data. Whether its type is ? object ? ? int ? or anything else doesn?t matter as long as it?s supposed to be the same. This doesn?t change anything in term of usage. Of course we should/could use map and usual operators on collections. What I was then proposing, to complete what you suggested and because I don?t like the dot notation, is using the matrix-multiplication the same way it is used in Julia with the dots. But I have a question. I never coded anything at C-level nor a compiler, is this possible for user defined types to make the vectorieation optimized the same way it?s done with numbers in numpy ? If yes, I think it would benefit the community. If no, it?s less likely, though it?s pursuing the steps made with typing On Sat 2 Feb 2019 at 10:23, Kirill Balunov wrote: > > > ??, 2 ????. 2019 ?. ? 07:33, Steven D'Aprano : > >> >> I didn't say anything about a vector type. >> >> > I agree you did not say. But since you started a new thread from the one > where the vector type was a little discussed, it seemed to me that it is > appropriate to mention it here. Sorry about that. > > >> > Therefore, it allows you to ensure that the method is present for each >> > element in the vector. The first given example is what numpy is all >> about >> > and without some guarantee that L consists of homogeneous data it hardly >> > make sense. >> >> Of course it makes sense. Even numpy supports inhomogeneous data: >> >> py> a = np.array([1, 'spam']) >> py> a >> array(['1', 'spam'], >> dtype='|S4') >> >> > Yes, numpy, at some degree, supports heterogeneous arrays. But not in the > way you brought it. Your example just shows homogeneous array of type > `'|S4'`. In the same way as `np.array([1, 1.234])` will be homogeneous. Of > course you can say - np.array([1, 'spam'], dtype='object'), but in this > case it will also be homogeneous array, but of type `object`. > > >> Inhomogeneous data may rule out some optimizations, but that hardly >> means that it "doesn't make sense" to use it. >> > > I did not say that it "doesn't make sense". I only said that you should > be lucky to call `..method()` on collections of heterogeneous data. And > therefore, usually this kind of operations imply that you are working with > a "homogeneous data". Unfortunately, built-in containers cannot provide > such a guarantee without self-checking. Therefore, in my opinion that at > the moment such an operator is not needed. > > With kind regards, > -gdg > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Feb 2 05:20:40 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 21:20:40 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: <20190202102032.GM1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 05:36:09PM -0600, Abe Dillon wrote: > B) I don't know of any forum system that allows you to misrepresent some > one else. Core developer Brett Cannon has taken up editing other people's comments on github if he doesn't approve of their tone. I'm now proactively editing people's comments on issues so they are less aggressive, e.g. "You need" becomes "it would be great if", etc. https://twitter.com/brettsky/status/1006660998860640256 And later: If they don't like it then I will simply ban them. Take note of how many people responding to Brett think it is a wonderful idea. The ability to edit other people's posts is considered a feature, not a bug. Github (currently) provides the full history of edits to each post. Reddit just has a flag that shows you whether a post was edited or not. Isn't technology wonderful? -- Steven From boxed at killingar.net Sat Feb 2 07:38:27 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Sat, 2 Feb 2019 13:38:27 +0100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <20190202084124.GJ1834@ando.pearwood.info> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: <78D6DD0D-7E36-4FCE-BC9F-5923D3946992@killingar.net> > Python has been around not quite 30 years now, so we can expect that it > will probably last another 30 years. But chances are not good that it > will be around in 300 years. With that attitude the odds go up *wink* / Anders From steve at pearwood.info Sat Feb 2 07:43:52 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sat, 2 Feb 2019 23:43:52 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: Message-ID: <20190202124352.GN1834@ando.pearwood.info> On Fri, Feb 01, 2019 at 11:40:37AM -0500, James Lu wrote: > So I want an open discussion on: How can we communicate clearer? Remember the Curse of Knowledge: just because you know something, don't imagine that all your readers know it too. https://en.wikipedia.org/wiki/Curse_of_knowledge https://www.psychologicalscience.org/observer/the-curse-of-knowledge-pinker-describes-a-key-cause-of-bad-writing https://sites.williams.edu/nk2/files/2011/08/Curse_of_Knowledge.pdf Try putting yourself in the reader's position. Will they understand what you are talking about? Re-read (and edit) your email for clarity before you hit send. Read your own email when it arrives in your inbox. If there are any major mistakes or confusing bits, reply to the list and clarify. With luck, maybe people will read your clarification before they respond. Try not to make rapid-fire knee-jerk responses to other people. (I know that's one bit of advice I personally find hard to follow.) Try to write clear and precise language. https://www.butte.edu/departments/cas/tipsheets/style_purpose_strategy/writing_clearly.html But note that *clear* and *precise* are often opposed to each other. The page above gives an example: The biota exhibited a one hundred percent mortality response. All the fish died. but the two sentences don't mean the same thing. (In the first, *everything* died; in the second, only the fish died.) Jargon is a double-edged sword for this reason: not everyone will know what the jargon means, but for those that do, jargon terms are both concise and precise in ways that plain English terms usually are not. As programmers, we use a lot of jargon, but remember than not everyone has the same background. My obvious technical term may be your obfuscatory gibberish. If you expect that a jargon term will be unfamiliar, either explain what you mean, or give a link to a site that explains it. If you're not sure whether a jargon term will be unfamiliar to others, remember the Curse of Knowledge: it probably will be. Remember that *most ideas are bad* -- that is equally true here as on Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Most_ideas_are_bad Be critical about your own ideas before you post. Try to anticipate objections. Either you will decide the objections are right, or you may be able to pre-empt them. Have a bit of humility: just because others disagree with you, doesn't mean that they haven't understood you. Perhaps they have understood your idea and its consequences better than you have yourself. It is *really hard* to read criticism of your ideas, but necessary. If the criticism was valid, then either your idea needs to fixed to avoid the problems given, or it needs to be abandoned as unfixable. Remember too that sometimes there is no right or wrong answer, just a matter of taste, or of value judgements. This especially applies when there are trade-offs involved. As a language, Python makes many trade-offs (as do all other languages). Some ideas are not bad in and of themselves, but they go against those trade-offs and consequently aren't a good fit for Python. On the flip side, sometimes we're too quick to reject ideas because they've never been done before. For some definition of "never". (Usually "never that I know of, not that I've looked too closely, or at all".) In my experience, Python programmers tend to be very conservative, perhaps more so than in other communities. Like cats, we often dislike things merely because they are new and different. Consequently sometimes its just a matter of patience and timing. Python as a language rarely is a trend-setter. Let other languages take the risks, we'll steal the ideas that work and leave those that don't. This conservativeness is only getting worse, as more of the core devs decide that we ought to slow the pace of change down even more, perhaps even halt it completely. I don't know what can be done about that. (Biologists have a word for complex systems which are stable: "dead".) -- Steven From phd at phdru.name Sat Feb 2 08:13:34 2019 From: phd at phdru.name (Oleg Broytman) Date: Sat, 2 Feb 2019 14:13:34 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: <20190202131334.oca4kojgegyxuh73@phdru.name> On Fri, Feb 01, 2019 at 08:40:22PM -0500, Terry Reedy wrote: > On 2/1/2019 3:31 PM, Oleg Broytman wrote: > > > Python REPL is missing the following batteries: > > That is why, on Windows, I nearly always use IDLE. > > > * Persistent history; > > IDLE's Shell history persists across restarts (which > are not available is the standard shell). I cannot remember wanting history > saved between IDLE sessions. I also cannot remember seeing a request for > this feature. If I want a sequence of commands saved, I copy them into an > editor window and save in a named file. > > > * Syntax highlighting; > > IDLE does this. > > > * Clear separation (using, for example, different colors) > > between input, output and errors; > > IDLE does this. For the question "Does Python REPL need more batteries?" is your answer "No, just point people to IDLE"? If it is - well, I disagree. I implemented a lot of enhancements for REPL myself, and I don't like and avoid GUI programs. > > * Paging of very long output/errors. > > Help output *is* paged in the standard shell. For comparison with IDLE, for > issue 35855, I tried out help(tkinter) in standard Python on both Windows > and Mac. For the most part, I found the pagers to be somewhat obnoxious and > deficient*. Except for one thing that I want to fix, paging up an down a > window with the standard PageUp and PageDown keys, as in IDLE, is easier and > better. And it is not limited I found pager ``less`` quite good. I configured it in a complex way, learned to use it and use in many different programs, not only Python. > * Windows Console holds a maximum of 9999 characters, with the default being > 300, at least for Command Prompt. The less pager, at least on Mac, when > invoked by help when running Python in Terminal, displays the paged output > in a separate window. When less is exited, the window closes and the paged > output *disappears*. > > You left out what I think is a very important 'battery': > * Works with Python statements instead of physical lines of text. > As I discussed elsewhere, this includes editing entire multiline statements > before submitting and storing and retrieving complete statements to and from > the history list. Yep, would be nice to have. Bash implements it somehow. > Here is another: > * Clicking on a traceback item can open the file in an editor at the > indicated line. That would be too much. Requires a traceback-sensitive pager. Also not very useful for situations where developer works on one host and runs programs on another (containers/virtual machines/remote hosts are widely used these days). > -- > Terry Jan Reedy Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From phd at phdru.name Sat Feb 2 08:15:48 2019 From: phd at phdru.name (Oleg Broytman) Date: Sat, 2 Feb 2019 14:15:48 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> Message-ID: <20190202131548.2gpuq6grzv7xoabi@phdru.name> On Fri, Feb 01, 2019 at 08:43:53PM -0600, eryk sun wrote: > On 2/1/19, Terry Reedy wrote: > > On 2/1/2019 3:31 PM, Oleg Broytman wrote: > > > >> Python REPL is missing the following batteries: > >> * Persistent history; > > Python's built-in REPL relies on the readline module for history. In > Windows you'll need to install pyreadline, an implementation that uses > the Windows console API via ctypes. Yep, I use it. The question is: Does Python REPL need this battery preinstalled and preconfigured; or any other battery as well? > Out of the box, Python uses the the built-in line editing and history > that's provided by the Windows console host (conhost.exe). There's an > undocumented function to read this history (as used by doskey.exe), > but there's no function to load lines into it. I suppose it could be > replayed manually in a loop that calls WriteConsoleInputW and > ReadConsoleW. Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From phd at phdru.name Sat Feb 2 08:21:45 2019 From: phd at phdru.name (Oleg Broytman) Date: Sat, 2 Feb 2019 14:21:45 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190202031006.GF1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202031006.GF1834@ando.pearwood.info> Message-ID: <20190202132145.q4i26knfbmgzs4jg@phdru.name> On Sat, Feb 02, 2019 at 02:10:06PM +1100, Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 09:31:21PM +0100, Oleg Broytman wrote: > > > Python REPL is missing the following batteries: > > > > * Persistent history; > > On Linux/Unix systems, that has been available for about 18+ years, > since the rlcompleter module was introduced in Python 2.0: > > https://docs.python.org/release/2.0/lib/module-rlcompleter.html > > It's been automatically enabled for more than six years: > > https://hg.python.org/cpython/rev/d5ef330bac50 I've configured my own .pythonrc long before that so I missed that it's now finally enabled. Thanks for pointing this out. > Windows is another story. > > > > * Syntax highlighting; > > bpython provides syntax highlighting in the REPL, but I've never seen > the point. In an editor, perhaps, but why bother in the REPL? > > https://bpython-interpreter.org/ > > So does DreamPie: > > http://www.dreampie.org/ > > > * Clear separation (using, for example, different colors) > > between input, output and errors; > > Input always starts with a prompt; And I have a different color just for prompt. > exception tracebacks always start > with the line "Traceback..."; other errors are generally not > programmatically distinguishable from non-errors. > > One could modify the displayhook and excepthook to deal with the usual > cases, but colour codes are not just platform-specific but console- > specific. > > https://docs.python.org/3.5/library/sys.html#sys.displayhook > > https://docs.python.org/3.5/library/sys.html#sys.excepthook > > > > * Paging of very long output/errors. > > I don't know how I feel about that. Now that Python shrinks long > tracebacks filled with identical lines, I'm not sure that this is so > important or desirable. > > >>> import sys > >>> sys.setrecursionlimit(30) > >>> def spam(): > ... spam() > ... > >>> spam() > Traceback (most recent call last): > File "", line 1, in > File "", line 2, in spam > File "", line 2, in spam > File "", line 2, in spam > [Previous line repeated 26 more times] > RecursionError: maximum recursion depth exceeded > -- > Steve Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From phd at phdru.name Sat Feb 2 08:24:16 2019 From: phd at phdru.name (Oleg Broytman) Date: Sat, 2 Feb 2019 14:24:16 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190202043735.GH1834@ando.pearwood.info> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202031006.GF1834@ando.pearwood.info> <20190202043735.GH1834@ando.pearwood.info> Message-ID: <20190202132416.whwcfehycys7o7jz@phdru.name> On Sat, Feb 02, 2019 at 03:37:36PM +1100, Steven D'Aprano wrote: > Sorry, I was not as clear as I ought to have been: > > On Sat, Feb 02, 2019 at 02:10:06PM +1100, Steven D'Aprano wrote: > > > > * Clear separation (using, for example, different colors) > > > between input, output and errors; > > > > Input always starts with a prompt; exception tracebacks always start > > with the line "Traceback..."; other errors are generally not > > programmatically distinguishable from non-errors. > > By which I mean, if a script or module reports an error by just printing > a message to the screen: > > print("sorry, an error occurred") > > sort of thing. Obviously the interpreter cannot guess which messages > represent errors in that sense and which are non-error output. > > (Of course, a script could format its own error messages, say by using > terminal-specific colour codes.) Scripts that report errors this way are broken and must be fixed: print("sorry, an error occurred", file=sys.stderr) Now it's easy to separate normal output from errors and colorize them differently. > -- > Steve Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From ricocotam at gmail.com Sat Feb 2 08:54:00 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sat, 2 Feb 2019 14:54:00 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190202124352.GN1834@ando.pearwood.info> References: <20190202124352.GN1834@ando.pearwood.info> Message-ID: Thanks Steve, that?s a good point, I might have been in one of the bad things you describe. It?s kinda funny that Python is conservative while being heavily used in the most recent techonologies (referring to machine learning). I personally think it?s not good but I might be too young for being conservative. Just a point about writing clear and precise English. For a good part of the audience and the writers, English is not our native language. Even if I?m considered good in English according to the standards in France, will far from being bilingual and expressing myself in English is not that easy. Technical discussions are not easy, no matter the language. Using a different language is harder and makes it really difficult some times. That?s why, in my case, I felt I mis expressed myself and proposed explanations on the answers I gave : I thought that was not clear because I?m not English-speaker. Another point, if when answering you (and others including me) you understood farther than the author, juste say what you understood further and all the implications. It will benefit everyone and discard ambiguities (especially for new-comers). On Sat 2 Feb 2019 at 13:45, Steven D'Aprano wrote: > On Fri, Feb 01, 2019 at 11:40:37AM -0500, James Lu wrote: > > > So I want an open discussion on: How can we communicate clearer? > > Remember the Curse of Knowledge: just because you know something, don't > imagine that all your readers know it too. > > https://en.wikipedia.org/wiki/Curse_of_knowledge > > > https://www.psychologicalscience.org/observer/the-curse-of-knowledge-pinker-describes-a-key-cause-of-bad-writing > > https://sites.williams.edu/nk2/files/2011/08/Curse_of_Knowledge.pdf > > Try putting yourself in the reader's position. Will they understand what > you are talking about? Re-read (and edit) your email for clarity before > you hit send. > > Read your own email when it arrives in your inbox. If there are any > major mistakes or confusing bits, reply to the list and clarify. With > luck, maybe people will read your clarification before they respond. > > Try not to make rapid-fire knee-jerk responses to other people. (I know > that's one bit of advice I personally find hard to follow.) > > Try to write clear and precise language. > > > https://www.butte.edu/departments/cas/tipsheets/style_purpose_strategy/writing_clearly.html > > But note that *clear* and *precise* are often opposed to each other. The > page above gives an example: > > The biota exhibited a one hundred percent mortality response. > > All the fish died. > > but the two sentences don't mean the same thing. (In the first, > *everything* died; in the second, only the fish died.) > > Jargon is a double-edged sword for this reason: not everyone will know > what the jargon means, but for those that do, jargon terms are both > concise and precise in ways that plain English terms usually are not. As > programmers, we use a lot of jargon, but remember than not everyone has > the same background. My obvious technical term may be your obfuscatory > gibberish. > > If you expect that a jargon term will be unfamiliar, either explain what > you mean, or give a link to a site that explains it. If you're not sure > whether a jargon term will be unfamiliar to others, remember the Curse > of Knowledge: it probably will be. > > Remember that *most ideas are bad* -- that is equally true here as on > Wikipedia: > > https://en.wikipedia.org/wiki/Wikipedia:Most_ideas_are_bad > > Be critical about your own ideas before you post. Try to anticipate > objections. Either you will decide the objections are right, or you may > be able to pre-empt them. > > Have a bit of humility: just because others disagree with you, doesn't > mean that they haven't understood you. Perhaps they have understood your > idea and its consequences better than you have yourself. > > It is *really hard* to read criticism of your ideas, but necessary. If > the criticism was valid, then either your idea needs to fixed to avoid > the problems given, or it needs to be abandoned as unfixable. > > Remember too that sometimes there is no right or wrong answer, just a > matter of taste, or of value judgements. This especially applies when > there are trade-offs involved. As a language, Python makes many > trade-offs (as do all other languages). Some ideas are not bad in and of > themselves, but they go against those trade-offs and consequently > aren't a good fit for Python. > > On the flip side, sometimes we're too quick to reject ideas because > they've never been done before. For some definition of "never". (Usually > "never that I know of, not that I've looked too closely, or at all".) In > my experience, Python programmers tend to be very conservative, perhaps > more so than in other communities. Like cats, we often dislike things > merely because they are new and different. > > Consequently sometimes its just a matter of patience and timing. Python > as a language rarely is a trend-setter. Let other languages take the > risks, we'll steal the ideas that work and leave those that don't. > > This conservativeness is only getting worse, as more of the core devs > decide that we ought to slow the pace of change down even more, perhaps > even halt it completely. I don't know what can be done about that. > > (Biologists have a word for complex systems which are stable: "dead".) > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sat Feb 2 08:54:22 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 08:54:22 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190202131334.oca4kojgegyxuh73@phdru.name> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> Message-ID: On Sat, Feb 2, 2019, 8:15 AM Oleg Broytman For the question "Does Python REPL need more batteries?" is your > answer "No, just point people to IDLE"? > If it is - well, I disagree. I implemented a lot of enhancements for > REPL myself, and I don't like and avoid GUI programs > IPython and BPython and Xonsh are projects that exist. I doubt the Python REPL will ever be as full featured as those, and I don't really think it should hope to. Similarly for IDLE or PyCharm or Spyder or Jupyter for folks who like GUIs. Apart from the maintenance work required for CPython (and for other Python implementations), the feature cadence is likely to be faster on those projects than is the Python core. That said, I definitely appreciate some small improvements in the REPL sooner the years, probably ones you have added, Oleg. So it's a balancing act, I recognize. -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Sat Feb 2 09:11:11 2019 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 2 Feb 2019 14:11:11 +0000 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190202124352.GN1834@ando.pearwood.info> Message-ID: On Sat, 2 Feb 2019 at 13:55, Adrien Ricocotam wrote: > Just a point about writing clear and precise English. For a good part of the audience and the writers, English is not our native language. Even if I?m considered good in English according to the standards in France, will far from being bilingual and expressing myself in English is not that easy. Technical discussions are not easy, no matter the language. Using a different language is harder and makes it really difficult some times. That?s why, in my case, I felt I mis expressed myself and proposed explanations on the answers I gave : I thought that was not clear because I?m not English-speaker. One point I will make - for myself (and maybe for the other native English speakers here) I find it really hard to determine when someone here is not a native speaker, basically because in general their English is so good that it's hard to tell! (I certainly couldn't communicate in any way effectively in French, which is the only language I could even claim to have a basic grasp of outside of English). So I'm sure some misunderstandings come from simply assuming people meant what they said, when in fact they were trying to say something slightly different, but didn't realise the nuances. It's hard to know what to do about this. As an English speaker I try to remember that not everyone is a native speaker, but being able to communicate effectively in another language *at all* is sufficiently foreign to my experience that I can't really understand the implications of being in that position. And expecting non-native speakers to continually remind us that they are speaking in a language other than their native one is unreasonable - not least because they are communicating better than many native speakers (in my experience). I guess the best answer is the usual one - assume good faith on everyone's part, and forgive minor inaccuracies. Also, while pedantic precision is common in technical discussions (and speaking for myself, something I often overindulge in for the fun of it...) it's better avoided in discussions on the list, where the fine distinctions involved may be lost on other participants. Paul From hasan.diwan at gmail.com Sat Feb 2 09:28:58 2019 From: hasan.diwan at gmail.com (Hasan Diwan) Date: Sat, 2 Feb 2019 06:28:58 -0800 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190202124352.GN1834@ando.pearwood.info> Message-ID: On Sat, 2 Feb 2019 at 06:12, Paul Moore wrote: > On Sat, 2 Feb 2019 at 13:55, Adrien Ricocotam wrote: > > Just a point about writing clear and precise English. For a good part of > the audience and the writers, English is not our native language. Even if > I?m considered good in English according to the standards in France, will > far from being bilingual and expressing myself in English is not that easy. > Technical discussions are not easy, no matter the language. Using a > different language is harder and makes it really difficult some times. > That?s why, in my case, I felt I mis expressed myself and proposed > explanations on the answers I gave : I thought that was not clear because > I?m not English-speaker. > Agreed 100%. There's also a cultural difference between, even, the UK and the US, whereby I'll mean certain things one way and have others interpret it differently. For example, the expression to "table" something, means the opposite across the pond. When my American colleagues say things like "let's table that", I always have to pinch myself to realise that means "put it off" and not "talk about it right now". And I **am** a native English speaker, despite what my name would lead some to believe. The above written, I have found that the python community, insofar as I've interacted with it, is more understanding and tolerant of these communication nuances when compared to other communities. -- H One point I will make - for myself (and maybe for the other native > English speakers here) I find it really hard to determine when someone > here is not a native speaker, basically because in general their > English is so good that it's hard to tell! (I certainly couldn't > communicate in any way effectively in French, which is the only > language I could even claim to have a basic grasp of outside of > English). So I'm sure some misunderstandings come from simply assuming > people meant what they said, when in fact they were trying to say > something slightly different, but didn't realise the nuances. > It's hard to know what to do about this. As an English speaker I try > to remember that not everyone is a native speaker, but being able to > communicate effectively in another language *at all* is sufficiently > foreign to my experience that I can't really understand the > implications of being in that position. And expecting non-native > speakers to continually remind us that they are speaking in a language > other than their native one is unreasonable - not least because they > are communicating better than many native speakers (in my experience). > > I guess the best answer is the usual one - assume good faith on > everyone's part, and forgive minor inaccuracies. Also, while pedantic > precision is common in technical discussions (and speaking for myself, > something I often overindulge in for the fun of it...) it's better > avoided in discussions on the list, where the fine distinctions > involved may be lost on other participants. > -- OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1 If you wish to request my time, please do so using *bit.ly/hd1AppointmentRequest *. Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest *. Sent from my mobile device Envoye de mon portable -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Sat Feb 2 09:47:32 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sat, 2 Feb 2019 15:47:32 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190202124352.GN1834@ando.pearwood.info> Message-ID: The community is really opened on the subject and I didn't receive any bad feelings about my English writing. I just wanted to remember everyone that a lot of us are non-native and despite the fact we speak well, we might not actually transmit exactly what we thought, nor understand what was meant. It's already not always the case when speaking native language. Actually my paragraph was more a point to introduce the following one : detailing what we said doesn't necessary mean we think the other is dumb. A lot of my sentence formulations are inspires by french and might mislead the understanding. A french would probably get what I mean, non-french will probably not. But we're focusing on something that's not the central subject here (even though it's pretty important). Le sam. 2 f?vr. 2019 ? 15:30, Hasan Diwan a ?crit : > > On Sat, 2 Feb 2019 at 06:12, Paul Moore wrote: > >> On Sat, 2 Feb 2019 at 13:55, Adrien Ricocotam >> wrote: >> > Just a point about writing clear and precise English. For a good part >> of the audience and the writers, English is not our native language. Even >> if I?m considered good in English according to the standards in France, >> will far from being bilingual and expressing myself in English is not that >> easy. Technical discussions are not easy, no matter the language. Using a >> different language is harder and makes it really difficult some times. >> That?s why, in my case, I felt I mis expressed myself and proposed >> explanations on the answers I gave : I thought that was not clear because >> I?m not English-speaker. >> > > Agreed 100%. > > There's also a cultural difference between, even, the UK and the US, > whereby I'll mean certain things one way and have others interpret it > differently. For example, the expression to "table" something, means the > opposite across the pond. When my American colleagues say things like > "let's table that", I always have to pinch myself to realise that means > "put it off" and not "talk about it right now". And I **am** a native > English speaker, despite what my name would lead some to believe. > > The above written, I have found that the python community, insofar as I've > interacted with it, is more understanding and tolerant of these > communication nuances when compared to other communities. -- H > > One point I will make - for myself (and maybe for the other native >> English speakers here) I find it really hard to determine when someone >> here is not a native speaker, basically because in general their >> English is so good that it's hard to tell! (I certainly couldn't >> communicate in any way effectively in French, which is the only >> language I could even claim to have a basic grasp of outside of >> English). So I'm sure some misunderstandings come from simply assuming >> people meant what they said, when in fact they were trying to say >> something slightly different, but didn't realise the nuances. > > >> It's hard to know what to do about this. As an English speaker I try >> to remember that not everyone is a native speaker, but being able to >> communicate effectively in another language *at all* is sufficiently >> foreign to my experience that I can't really understand the >> implications of being in that position. And expecting non-native >> speakers to continually remind us that they are speaking in a language >> other than their native one is unreasonable - not least because they >> are communicating better than many native speakers (in my experience). >> >> I guess the best answer is the usual one - assume good faith on >> everyone's part, and forgive minor inaccuracies. Also, while pedantic >> precision is common in technical discussions (and speaking for myself, >> something I often overindulge in for the fun of it...) it's better >> avoided in discussions on the list, where the fine distinctions >> involved may be lost on other participants. >> > -- > OpenPGP: > https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1 > If you wish to request my time, please do so using *bit.ly/hd1AppointmentRequest > *. > Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest > *. > > Sent > from my mobile device > Envoye de mon portable > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Sat Feb 2 13:13:42 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sat, 2 Feb 2019 18:13:42 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202085835.GK1834@ando.pearwood.info> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <20190202085835.GK1834@ando.pearwood.info> Message-ID: <0d545af3-3fbf-adea-f7b7-2916003fc723@mrabarnett.plus.com> On 2019-02-02 08:58, Steven D'Aprano wrote: > On Sat, Feb 02, 2019 at 05:10:14AM +0000, MRAB wrote: >> On 2019-02-02 04:32, Steven D'Aprano wrote: >> [snip] >> > >> >Of course it makes sense. Even numpy supports inhomogeneous data: >> > >> [snip] >> >> "inhomogeneous"? Who came up with that? > > I don't know, but it has been used since at least the early 1920s > > https://english.stackexchange.com/questions/194906/heterogeneous-vs-inhomogeneous > > and the Oxford dictionary describes "inhomogenity" as being used from > the late 19th century. So my guess is, probably people who were more > familiar with Latin and Greek than we are. > > There are many words that are derived from both Latin and Greek. There's > no rule that says that because a word was derived from Greek, we must > use Greek grammatical forms for it. We are speaking English, not Greek, > and in English, we can negate words using the "in" prefix. > Well, if we were using an English prefix, wouldn't it be "unhomogeneous"? From python at mrabarnett.plus.com Sat Feb 2 13:25:48 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sat, 2 Feb 2019 18:25:48 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> Message-ID: <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> On 2019-02-02 09:22, Kirill Balunov wrote: > > > ??, 2 ????. 2019 ?. ? 07:33, Steven D'Aprano >: > > > I didn't say anything about a vector type. > > > I agree? you did not say. But since you started a new thread from the > one where the vector type was a little discussed, it seemed to me? that > it is appropriate to mention it here. Sorry about that. > > > Therefore, it allows you to ensure that the method is present for > each > > element in the vector. The first given example is what numpy is > all about > > and without some guarantee that L consists of homogeneous data it > hardly > > make sense. > > Of course it makes sense. Even numpy supports inhomogeneous data: > > py> a = np.array([1, 'spam']) > py> a > array(['1', 'spam'], > ? ? ? dtype='|S4') > > > Yes, numpy, at some degree, supports heterogeneous arrays.?But not in > the way you brought it. Your example just shows homogeneous array of > type `'|S4'`.?In the same way as `np.array([1, 1.234])` will be > homogeneous. Of course you can say -? np.array([1, 'spam'], > dtype='object'), but in this case it will also be homogeneous array, but > of type `object`. > > Inhomogeneous data may rule out some optimizations, but that hardly > means that it "doesn't make sense" to use it. > > > I did not say that it? "doesn't make sense". I only said that you should > be lucky to call `..method()` on collections of heterogeneous data.?And > therefore, usually this kind of operations imply that you are working > with a "homogeneous data". Unfortunately, built-in containers cannot > provide such a guarantee without self-checking.?Therefore, in my opinion > that at the moment such an operator is not needed. > Here's a question: when you use a subscript on a vector, does it apply to the vector itself, or its members? For example, given: >>> my_strings = Vector(['one', 'two', 'three']) what is: >>> my_strings[1 : ] ? Is it: Vector(['ne', 'wo', 'hree']) or: Vector(['two', 'three']) ? From ricocotam at gmail.com Sat Feb 2 12:31:47 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sat, 2 Feb 2019 18:31:47 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> Message-ID: I personally would the first option to be the case. But then vectors shouldn't be list-like but more generator like. Le sam. 2 f?vr. 2019 ? 19:26, MRAB a ?crit : > On 2019-02-02 09:22, Kirill Balunov wrote: > > > > > > ??, 2 ????. 2019 ?. ? 07:33, Steven D'Aprano > >: > > > > > > I didn't say anything about a vector type. > > > > > > I agree you did not say. But since you started a new thread from the > > one where the vector type was a little discussed, it seemed to me that > > it is appropriate to mention it here. Sorry about that. > > > > > Therefore, it allows you to ensure that the method is present for > > each > > > element in the vector. The first given example is what numpy is > > all about > > > and without some guarantee that L consists of homogeneous data it > > hardly > > > make sense. > > > > Of course it makes sense. Even numpy supports inhomogeneous data: > > > > py> a = np.array([1, 'spam']) > > py> a > > array(['1', 'spam'], > > dtype='|S4') > > > > > > Yes, numpy, at some degree, supports heterogeneous arrays. But not in > > the way you brought it. Your example just shows homogeneous array of > > type `'|S4'`. In the same way as `np.array([1, 1.234])` will be > > homogeneous. Of course you can say - np.array([1, 'spam'], > > dtype='object'), but in this case it will also be homogeneous array, but > > of type `object`. > > > > Inhomogeneous data may rule out some optimizations, but that hardly > > means that it "doesn't make sense" to use it. > > > > > > I did not say that it "doesn't make sense". I only said that you should > > be lucky to call `..method()` on collections of heterogeneous data. And > > therefore, usually this kind of operations imply that you are working > > with a "homogeneous data". Unfortunately, built-in containers cannot > > provide such a guarantee without self-checking. Therefore, in my opinion > > that at the moment such an operator is not needed. > > > Here's a question: when you use a subscript on a vector, does it apply > to the vector itself, or its members? > > For example, given: > > >>> my_strings = Vector(['one', 'two', 'three']) > > what is: > > >>> my_strings[1 : ] > > ? > > Is it: > > Vector(['ne', 'wo', 'hree']) > > or: > > Vector(['two', 'three']) > > ? > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Sat Feb 2 13:44:55 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sat, 2 Feb 2019 18:44:55 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> Message-ID: <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> On 2019-02-02 17:31, Adrien Ricocotam wrote: > I personally would the first option to be the case. But then vectors shouldn't be list-like but more generator like. > OK, here's another one: if you use 'list(...)' on a vector, does it apply to the vector itself or its members? >>> list(my_strings) You might be wanting to convert a vector into a list: ['one', 'two', 'three'] or convert each of its members onto lists: Vector([['one'], ['two'], ['three']]) > Le sam. 2 f?vr. 2019 ? 19:26, MRAB a ?crit : > >???? On 2019-02-02 09:22, Kirill Balunov wrote: >???? > >???? > >???? > ??, 2 ????. 2019 ?. ? 07:33, Steven D'Aprano ???? > >: >???? > >???? > >???? >???? I didn't say anything about a vector type. >???? > >???? > >???? > I agree? you did not say. But since you started a new thread from the >???? > one where the vector type was a little discussed, it seemed to me? that >???? > it is appropriate to mention it here. Sorry about that. >???? > >???? >????? > Therefore, it allows you to ensure that the method is present for >???? >???? each >???? >????? > element in the vector. The first given example is what numpy is >???? >???? all about >???? >????? > and without some guarantee that L consists of homogeneous data it >???? >???? hardly >???? >????? > make sense. >???? > >???? >???? Of course it makes sense. Even numpy supports inhomogeneous data: >???? > >???? >???? py> a = np.array([1, 'spam']) >???? >???? py> a >???? >???? array(['1', 'spam'], >???? >??????????? dtype='|S4') >???? > >???? > >???? > Yes, numpy, at some degree, supports heterogeneous arrays. But not in >???? > the way you brought it. Your example just shows homogeneous array of >???? > type `'|S4'`. In the same way as `np.array([1, 1.234])` will be >???? > homogeneous. Of course you can say -? np.array([1, 'spam'], >???? > dtype='object'), but in this case it will also be homogeneous array, but >???? > of type `object`. >???? > >???? >???? Inhomogeneous data may rule out some optimizations, but that hardly >???? >???? means that it "doesn't make sense" to use it. >???? > >???? > >???? > I did not say that it? "doesn't make sense". I only said that you should >???? > be lucky to call `..method()` on collections of heterogeneous data. And >???? > therefore, usually this kind of operations imply that you are working >???? > with a "homogeneous data". Unfortunately, built-in containers cannot >???? > provide such a guarantee without self-checking. Therefore, in my opinion >???? > that at the moment such an operator is not needed. >???? > >???? Here's a question: when you use a subscript on a vector, does it apply >???? to the vector itself, or its members? > >???? For example, given: > >????? >>> my_strings = Vector(['one', 'two', 'three']) > >???? what is: > >????? >>> my_strings[1 : ] > >???? ? > >???? Is it: > >???? Vector(['ne', 'wo', 'hree']) > >???? or: > >???? Vector(['two', 'three']) > >???? ? From ricocotam at gmail.com Sat Feb 2 12:48:26 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sat, 2 Feb 2019 18:48:26 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> Message-ID: That's tough. I'd say conver the vector to a list. But : my_vector.list() Would apply list on each element of the vector. Globally, I'd say if the vector is used as an argument, it's a usual iterable, if you use a member function (or any other notation like @ or .. or whatever) it's like map. Note that it's just my opinion. Le sam. 2 f?vr. 2019 ? 19:46, MRAB a ?crit : > On 2019-02-02 17:31, Adrien Ricocotam wrote: > > I personally would the first option to be the case. But then vectors > shouldn't be list-like but more generator like. > > > OK, here's another one: if you use 'list(...)' on a vector, does it > apply to the vector itself or its members? > > >>> list(my_strings) > > You might be wanting to convert a vector into a list: > > ['one', 'two', 'three'] > > or convert each of its members onto lists: > > Vector([['one'], ['two'], ['three']]) > > > Le sam. 2 f?vr. 2019 ? 19:26, MRAB a > ?crit : > > > > On 2019-02-02 09:22, Kirill Balunov wrote: > > > > > > > > > ??, 2 ????. 2019 ?. ? 07:33, Steven D'Aprano > > >: > > > > > > > > > I didn't say anything about a vector type. > > > > > > > > > I agree you did not say. But since you started a new thread > from the > > > one where the vector type was a little discussed, it seemed to > me that > > > it is appropriate to mention it here. Sorry about that. > > > > > > > Therefore, it allows you to ensure that the method is > present for > > > each > > > > element in the vector. The first given example is what > numpy is > > > all about > > > > and without some guarantee that L consists of > homogeneous data it > > > hardly > > > > make sense. > > > > > > Of course it makes sense. Even numpy supports inhomogeneous > data: > > > > > > py> a = np.array([1, 'spam']) > > > py> a > > > array(['1', 'spam'], > > > dtype='|S4') > > > > > > > > > Yes, numpy, at some degree, supports heterogeneous arrays. But > not in > > > the way you brought it. Your example just shows homogeneous > array of > > > type `'|S4'`. In the same way as `np.array([1, 1.234])` will be > > > homogeneous. Of course you can say - np.array([1, 'spam'], > > > dtype='object'), but in this case it will also be homogeneous > array, but > > > of type `object`. > > > > > > Inhomogeneous data may rule out some optimizations, but > that hardly > > > means that it "doesn't make sense" to use it. > > > > > > > > > I did not say that it "doesn't make sense". I only said that > you should > > > be lucky to call `..method()` on collections of heterogeneous > data. And > > > therefore, usually this kind of operations imply that you are > working > > > with a "homogeneous data". Unfortunately, built-in containers > cannot > > > provide such a guarantee without self-checking. Therefore, in > my opinion > > > that at the moment such an operator is not needed. > > > > > Here's a question: when you use a subscript on a vector, does it > apply > > to the vector itself, or its members? > > > > For example, given: > > > > >>> my_strings = Vector(['one', 'two', 'three']) > > > > what is: > > > > >>> my_strings[1 : ] > > > > ? > > > > Is it: > > > > Vector(['ne', 'wo', 'hree']) > > > > or: > > > > Vector(['two', 'three']) > > > > ? > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ja.py at farowl.co.uk Sat Feb 2 14:58:34 2019 From: ja.py at farowl.co.uk (Jeff Allen) Date: Sat, 2 Feb 2019 19:58:34 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> Message-ID: <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> On 02/02/2019 18:44, MRAB wrote: > On 2019-02-02 17:31, Adrien Ricocotam wrote: > > I personally would the first option to be the case. But then vectors > shouldn't be list-like but more generator like. > > > OK, here's another one: if you use 'list(...)' on a vector, does it > apply to the vector itself or its members? > > >>> list(my_strings) > > You might be wanting to convert a vector into a list: > > ['one', 'two', 'three'] > > or convert each of its members onto lists: > > Vector([['one'], ['two'], ['three']]) > More likely you mean: >>> [list(i) for i in ['one', 'two', 'three']] [['o', 'n', 'e'], ['t', 'w', 'o'], ['t', 'h', 'r', 'e', 'e']] The problem, of course, is that list() now has to understand Vector specially, and so does any function you think of applying to it. Operators are easier (even those like [1:]) because Vector can make its own definition of each through (a finite set of) dunder methods. To make a Vector accept an arbitrarily-named method call like my_strings.upper() to mean: >>> [i.upper() for i in ['one', 'two', 'three']] ['ONE', 'TWO', 'THREE'] is perhaps just about possible by manipulating __getattribute__ to resolve names matching methods on the underlying type to a callable that loops over the content. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sat Feb 2 15:31:29 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 15:31:29 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> Message-ID: I still haven't seen any examples that aren't already spelled 'map(fun, it)' On Sat, Feb 2, 2019, 3:17 PM Jeff Allen On 02/02/2019 18:44, MRAB wrote: > > On 2019-02-02 17:31, Adrien Ricocotam wrote: > > I personally would the first option to be the case. But then vectors > shouldn't be list-like but more generator like. > > > OK, here's another one: if you use 'list(...)' on a vector, does it apply > to the vector itself or its members? > > >>> list(my_strings) > > You might be wanting to convert a vector into a list: > > ['one', 'two', 'three'] > > or convert each of its members onto lists: > > Vector([['one'], ['two'], ['three']]) > > More likely you mean: > > >>> [list(i) for i in ['one', 'two', 'three']] > [['o', 'n', 'e'], ['t', 'w', 'o'], ['t', 'h', 'r', 'e', 'e']] > > The problem, of course, is that list() now has to understand Vector > specially, and so does any function you think of applying to it. Operators > are easier (even those like [1:]) because Vector can make its own > definition of each through (a finite set of) dunder methods. To make a > Vector accept an arbitrarily-named method call like my_strings.upper() to > mean: > > >>> [i.upper() for i in ['one', 'two', 'three']] > ['ONE', 'TWO', 'THREE'] > > is perhaps just about possible by manipulating __getattribute__ to resolve > names matching methods on the underlying type to a callable that loops over > the content. > > Jeff > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brenbarn at brenbarn.net Sat Feb 2 15:44:29 2019 From: brenbarn at brenbarn.net (Brendan Barnwell) Date: Sat, 02 Feb 2019 12:44:29 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> Message-ID: <5C56012D.1000704@brenbarn.net> On 2019-02-02 12:31, David Mertz wrote: > I still haven't seen any examples that aren't already spelled 'map(fun, it)' The problem with this is the same problem with having a function called "add" instead of an operator. There is little gain when you're applying ONE function, but if you're applying multiple functions you get a thicket of parentheses. I would rather see this: some_list @ str.lower @ tokenize @ remove_stopwords . . .than this: map(remove_stopwords, map(tokenize, map(str.lower, some_list))) That said, I don't necessarily think this needs to be added to the language. Things like pandas already provide this and so much more that it's unclear whether the gain from adding vectorization on its own would be worth it. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown From steve at pearwood.info Sat Feb 2 17:36:18 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 09:36:18 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> Message-ID: <20190202223618.GO1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 07:58:34PM +0000, Jeff Allen wrote: [MRAB asked] > >OK, here's another one: if you use 'list(...)' on a vector, does it > >apply to the vector itself or its members? With the Julia vectorization operator, there is no puzzle there. list(vector) applies list to the vector itself. list.(vector) applies list to each component of vector. > The problem, of course, is that list() now has to understand Vector > specially, and so does any function you think of applying to it. *The whole point* of the Julia syntax is that no function has to understand any sequence. When we write: for item in vector: func(item) func only has to understand item, not vector. The same applies to the Julia syntax func.(vector) There's no puzzle here, no tricky cases, because it is completely deterministic and explicit: func(x) always calls func with x as argument, func.(x) always calls func with each of x's items as arguments. > Operators are easier (even those like [1:]) because Vector can make its > own definition of each through (a finite set of) dunder methods. To make > a Vector accept an arbitrarily-named method call like my_strings.upper() > to mean: With the Julia syntax, there is no need for vectors (or lists, or generators, or tuples, or sets, or any other iterator...) to accept arbitrary method calls. So long as vectors can be iterated over, func.(vector) will work. From mertz at gnosis.cx Sat Feb 2 18:08:24 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 18:08:24 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202223618.GO1834@ando.pearwood.info> References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202223618.GO1834@ando.pearwood.info> Message-ID: Beyond possibly saving 3-5 characters, I continue not to see anything different from map in this discussion. list(vector) applies list to the vector itself. > list.(vector) applies list to each component of vector. > In Python: list(seq) applies list to the sequence itself map(list, seq) applies list to each component of seq In terms of other examples: map(str.upper, seq) uppercases each item map(operator.attrgetter('name'), seq) gets the name attribute of each item map(lambda a: a*2, seq) doubles each item (lambda a: a*2)(seq) doubles the sequence itself ... Last two might enjoy named function 'double' > > The problem, of course, is that list() now has to understand Vector > > specially, and so does any function you think of applying to it. > > *The whole point* of the Julia syntax is that no function has to > understand any sequence. When we write: > > for item in vector: > func(item) > > func only has to understand item, not vector. The same applies to the > Julia syntax > > func.(vector) > > There's no puzzle here, no tricky cases, because it is completely > deterministic and explicit: func(x) always calls func with x as > argument, func.(x) always calls func with each of x's items as > arguments. > > > > > Operators are easier (even those like [1:]) because Vector can make its > > own definition of each through (a finite set of) dunder methods. To make > > a Vector accept an arbitrarily-named method call like my_strings.upper() > > to mean: > > With the Julia syntax, there is no need for vectors (or lists, or > generators, or tuples, or sets, or any other iterator...) to accept > arbitrary method calls. So long as vectors can be iterated over, > func.(vector) will work. > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Feb 2 18:11:02 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 10:11:02 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> Message-ID: <20190202231101.GP1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 03:31:29PM -0500, David Mertz wrote: > I still haven't seen any examples that aren't already spelled 'map(fun, it)' You might be right. But then there's nothing that map() can do that couldn't be written as a comprehension, and nothing that you can't do with a comprehension that can't be written as a for-loop. And nothing that can't be written as a for-loop that couldn't be written as a while-loop. The only loop construct we really need is a while loop. And even that is redundant if we had GOTO. Its not about the functionality, but expressibility and readability. This hypothetical vectorization syntax might have a performance advantage as well. My understanding is that Julia is able to efficiently vectorize code, bringing it to within 10% of the speed of unrolled C loops. It may be that CPython cannot do anything that fast, but there may be some opportunities for optimization that we cannot apply to for-loops or comprehensions due to the way they are defined. But primarily it is about the readability of the code: result = process.(vector .+ sequence) .* items versus: # Ouch! result = map(operator.mul, zip(map(process, map(operator.add, zip(vector, sequence)), items)) Here's the comprehension version: result = [a*b for a, b in zip( [process(c) for c in [d+e for d, e in zip(vector, sequence)]], items)] We can improve that comprehension a tiny bit by splitting it into multiple steps: temp1 = [d+e for d, e in zip(vector, sequence)] temp2 = [process(c) for x in temp1] result = [a*b for a, b in zip(temp2, items)] but none of these are as elegant or readable as the vectorized syntax result = process.(vector .+ sequence) .* items -- Steve From pythonchb at gmail.com Sat Feb 2 18:22:12 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sat, 2 Feb 2019 15:22:12 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: On Fri, Feb 1, 2019 at 5:00 PM David Mertz wrote: > is is certainly doable. But why would it be better than: >> > > map(str.lower, my_string_vector) > map(compute_grad, my_student_vector) > or [s.lower() for s in my_string_vector] Side note: It's really interesting to me that Python introduced comprehension sytax some years ago, and even "hid" reduce(), and now there seems to be a big interest / revival of "map". Even numpy supports inhomogeneous data: > py> a = np.array([1, 'spam']) > py> a > array(['1', 'spam'], > dtype='|S4') well, no -- it doesn't -- look carefully, that is an array or type '!S4' -- i,e, a 4 element long string --every element in that array is that same type. Also note that numpy's support for strings a not very complete. numpy does support an "object" type, that can be inhomogeneous -- it's still a single type, but that type is a python object (under the hood it's an array fo pointers to pyobjects): In [3]: a = np.array([1, 'spam'], dtype=np.object) In [4]: a Out[4]: array([1, 'spam'], dtype=object) And it does support vectorization to some extent: In [5]: a * 5 Out [5]: array([5, 'spamspamspamspamspam'], dtype=object) But not with any performance benefits. I think there are good reasons to have a "string_vector" that is known to be homogenous: Performance -- it could be significantly optimized (are there many use cases for that? I don't know. Clear API: a string_vector would have all the relevant string methods. You could easily write a list subclass that passed on method calls to the enclosed objects, but then you'd have a fair bit of confusion as to what might be a vector method vs a method on the objects. which I suppose leaves us with something like: list.elements.upper() list.elements * 5 hmm -- not sure how much I like this, but it's pretty doable. I still haven't seen any examples that aren't already spelled 'map(fun, it)' and I don't think you will -- I *think* get credit for starting this part of the the thread, and I started by saying I have often longed for essentially a more concise way to spell map() or comprehensions. performance asside, I use numpy because: c = np.sqrt(a**2 + b**2) is a heck of a lot easer to read, write, and get correct than: c = list(map(math.sqrt, map(lambda x, y: x + y, map(lambda x: x**2, a), map(lambda x: x**2, b) ))) or: [math.sqrt(x) for x in (a + b for a, b in zip((x**2 for x in a), (x**2 for x in b) ))] Note: it took me quite a while to get those right! (and I know I could have used the operator module to get the map version maybe a bit cleaner, but the point stands) Does this apply to string processing? I'm not sure, though I do a fair bit of chaining of string operations: my_string.strip().lower().title() if you wanted to do that to a list of strings: a_list_of_strings.strip().lower().title() is a lot nicer than: [s.title() for s in (s.lower() for s in [s.strip(s) for s in a_list_of_strings])] or list(map(str.title, (map(str.lower, (map(str.strip, a_list_of_strings)))) # untested How common is that use case? not common enough for me to go any further with this. -CHB -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Feb 2 18:30:40 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 10:30:40 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202223618.GO1834@ando.pearwood.info> Message-ID: <20190202233040.GQ1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 06:08:24PM -0500, David Mertz wrote: > In terms of other examples: > > map(str.upper, seq) uppercases each item > map(operator.attrgetter('name'), seq) gets the name attribute of each item > map(lambda a: a*2, seq) doubles each item Now compose those operations: ((seq .* 2)..name)..upper() versus # Gag me with a spoon! map(str.upper, map(operator.attrgetter('name'), map(lambda a: a*2, seq))) The comprehension version isn't awful: [(a*2).name.upper() for a in seq] but not all vectorized operations can be written as a chain of calls on a single sequence. There are still some open issues that I don't have good answers for. Consider ``x .+ y``. In Julia, I think that the compiler has enough type information to distinguish between the array plus scalar and array plus array cases, but I don't think Python will have that. So possibly there will still be some runtime information needed to make this work. The dot arguably fails the "syntax should not look like grit on Tim's monitor" test (although attribute access already fails that test). I think the double-dot syntax looks like a typo, which is unfortunate. -- Steve From benrudiak at gmail.com Sat Feb 2 18:35:13 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Sat, 2 Feb 2019 15:35:13 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker wrote: > performance asside, I use numpy because: > > c = np.sqrt(a**2 + b**2) > > is a heck of a lot easer to read, write, and get correct than: > > c = list(map(math.sqrt, map(lambda x, y: x + y, map(lambda x: x**2, a), > map(lambda x: x**2, b) > ))) > > or: > > [math.sqrt(x) for x in (a + b for a, b in zip((x**2 for x in a), > (x**2 for x in b) > ))] > You can also write c = [math.sqrt(x**2 + y**2) for x, y in zip(a, b)] or c = list(map(lambda x, y: math.sqrt(x**2 + y**2), a, b)) or, since math.hypot exists, c = list(map(math.hypot, a, b)) In recent Python versions you can write [*map(...)] instead of list(map(...)), which I find more readable. a_list_of_strings.strip().lower().title() > > is a lot nicer than: > > [s.title() for s in (s.lower() for s in [s.strip(s) for s in > a_list_of_strings])] > > or > > list(map(str.title, (map(str.lower, (map(str.strip, a_list_of_strings)))) > # untested > In this case you can write [s.strip().lower().title() for s in a_list_of_strings] -- Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sat Feb 2 18:36:03 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 3 Feb 2019 10:36:03 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202233040.GQ1834@ando.pearwood.info> References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202223618.GO1834@ando.pearwood.info> <20190202233040.GQ1834@ando.pearwood.info> Message-ID: On Sun, Feb 3, 2019 at 10:31 AM Steven D'Aprano wrote: > The dot arguably fails the "syntax should not look like grit on Tim's > monitor" test (although attribute access already fails that test). I > think the double-dot syntax looks like a typo, which is unfortunate. Agreed, so I would like to see a different spelling of it. Pike has an automap syntax that looks a lot like subscripting: numbers[*] * 2 Borrowing that syntax would pass the grit test, and it currently isn't valid syntax. ChrisA From jamtlu at gmail.com Sat Feb 2 10:57:40 2019 From: jamtlu at gmail.com (James Lu) Date: Sat, 2 Feb 2019 10:57:40 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: It?s very demotivating to hear just negative feedback on this list. Was starting this thread useful for y?all? From jamtlu at gmail.com Sat Feb 2 11:04:40 2019 From: jamtlu at gmail.com (James Lu) Date: Sat, 2 Feb 2019 11:04:40 -0500 Subject: [Python-ideas] What factors led Guido to quit? Message-ID: I want y?all to think about this very carefully. What factors led Guido to quit? And I don?t want you to just reply with the first thing that comes off your head. The purpose of this question/discussion is to identify problems with the Python community so we can fix them. That is the only real chance of having a successful Python language that doesn?t get left behind by other languages, or of getting Guido to come back. From jamtlu at gmail.com Sat Feb 2 11:12:02 2019 From: jamtlu at gmail.com (James Lu) Date: Sat, 2 Feb 2019 11:12:02 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> Message-ID: <57D1197E-DC26-4764-95EB-9128BEB314EF@gmail.com> This list IS hard for newcomers. I wish there was one place where I could read up on how to not feel like a noob. From jamtlu at gmail.com Sat Feb 2 10:59:36 2019 From: jamtlu at gmail.com (James Lu) Date: Sat, 2 Feb 2019 10:59:36 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: I think we need to step away from the egalitarian ideal and have some way of knowing that Python committees are python committers. It?s really difficult to know how well your proposal is doing without having this. From steve at pearwood.info Sat Feb 2 18:40:23 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 10:40:23 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: <20190202234022.GR1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 03:22:12PM -0800, Christopher Barker wrote: [This bit was me] > Even numpy supports inhomogeneous data: > > py> a = np.array([1, 'spam']) > > py> a > > array(['1', 'spam'], > > dtype='|S4') > > > well, no -- it doesn't -- look carefully, that is an array or type '!S4' -- > i,e, a 4 element long string --every element in that array is that same > type. So it is. I wondered what the cryptic '|S4' symbol meant, and I completely missed the '' quotes around the 1. Thanks for the correction. [...] > c = np.sqrt(a**2 + b**2) > > is a heck of a lot easer to read, write, and get correct than: > > c = list(map(math.sqrt, map(lambda x, y: x + y, map(lambda x: x**2, a), > map(lambda x: x**2, b) > ))) Indeed. This hypothetical syntax brings the readability advantages of infix operators to code that operates on iterables, without requiring every iterable to support arbitrary functions and methods. -- Steve From mertz at gnosis.cx Sat Feb 2 18:43:51 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 18:43:51 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019, 6:23 PM Christopher Barker > a_list_of_strings.strip().lower().title() > > is a lot nicer than: > > [s.title() for s in (s.lower() for s in [s.strip(s) for s in > a_list_of_strings])] > > or > > list(map(str.title, (map(str.lower, (map(str.strip, a_list_of_strings)))) > # untested > I'm warming up some. But is this imagined as vectors of strings, or as generically homogeneous objects? And what is homogeneity exactly in the face of duck typing? Absent the vector wrapping, I think I might write this for your example: map(lambda s: s..strip().lower().title(), a_list_of_strings) That's slightly longer, but just by the length of the word lambda. One could write a wrapper to vectorize pretty easily. So maybe: Vector(a_list_of_strings).strip().lower().title() This would just pass along the methods to the individual items, and wouldn't need to think about typing per se. Maybe other objects happen to have those three methods, so are string-like in a duck way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sat Feb 2 18:46:20 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 3 Feb 2019 10:46:20 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: On Sun, Feb 3, 2019 at 10:36 AM Ben Rudiak-Gould wrote: > > On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker wrote: >> >> a_list_of_strings.strip().lower().title() >> >> is a lot nicer than: >> >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in a_list_of_strings])] >> >> or >> >> list(map(str.title, (map(str.lower, (map(str.strip, a_list_of_strings)))) # untested > > In this case you can write > > [s.strip().lower().title() for s in a_list_of_strings] What if it's a more complicated example? len(sorted(a_list_of_strings.casefold())[:100]) where the len() is supposed to give back a list of the lengths of the first hundred strings, sorted case insensitively? (Okay so it's a horrible contrived example. Bear with me.) With current syntax, this would need multiple map calls or comprehensions: [len(s) for s in sorted(s.casefold() for s in a_list_of_strings)[:100]] (Better examples welcomed.) ChrisA From mertz at gnosis.cx Sat Feb 2 18:47:35 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 18:47:35 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: My double dot was a typo on my tablet, not borrowing Julia syntax, in this case. On Sat, Feb 2, 2019, 6:43 PM David Mertz On Sat, Feb 2, 2019, 6:23 PM Christopher Barker > >> a_list_of_strings.strip().lower().title() >> >> is a lot nicer than: >> >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in >> a_list_of_strings])] >> >> or >> >> list(map(str.title, (map(str.lower, (map(str.strip, a_list_of_strings)))) >> # untested >> > > I'm warming up some. But is this imagined as vectors of strings, or as > generically homogeneous objects? And what is homogeneity exactly in the > face of duck typing? > > Absent the vector wrapping, I think I might write this for your example: > > map(lambda s: s..strip().lower().title(), a_list_of_strings) > > That's slightly longer, but just by the length of the word lambda. > > One could write a wrapper to vectorize pretty easily. So maybe: > > Vector(a_list_of_strings).strip().lower().title() > > This would just pass along the methods to the individual items, and > wouldn't need to think about typing per se. Maybe other objects happen to > have those three methods, so are string-like in a duck way. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benrudiak at gmail.com Sat Feb 2 18:54:18 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Sat, 2 Feb 2019 15:54:18 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202233040.GQ1834@ando.pearwood.info> References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202223618.GO1834@ando.pearwood.info> <20190202233040.GQ1834@ando.pearwood.info> Message-ID: On Sat, Feb 2, 2019 at 3:31 PM Steven D'Aprano wrote: > The comprehension version isn't awful: > > [(a*2).name.upper() for a in seq] > > but not all vectorized operations can be written as a chain of calls on > a single sequence. > If they are strictly parallel (no dot products) and you know when writing the code which variables hold vectors, then (denoting the vector variables by v1, ..., vn) you can always write [(expr with x1, ..., xn substituted for v1, ..., vn) for x1, ..., xn in zip(v1, ..., vn)] which seems not much worse than the auto-vectorized version (with or without special syntax). Haskell (GHC) has parallel list comprehension syntax ( https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#parallel-list-comprehensions) so you don't have to explicitly call zip. I wouldn't mind having that in Python but I don't know what the syntax would be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sat Feb 2 19:00:05 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 11:00:05 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: <20190203000005.GS1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 10:59:36AM -0500, James Lu wrote: > I think we need to step away from the egalitarian ideal and have some > way of knowing that Python committees are python committers. It?s > really difficult to know how well your proposal is doing without > having this. Speaking of clearer communication (see the subject line), who are you referring to and which proposal do you mean? -- Steven From steve at pearwood.info Sat Feb 2 19:17:48 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 11:17:48 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: <57D1197E-DC26-4764-95EB-9128BEB314EF@gmail.com> References: <20190201183836.GU1834@ando.pearwood.info> <57D1197E-DC26-4764-95EB-9128BEB314EF@gmail.com> Message-ID: <20190203001747.GT1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 11:12:02AM -0500, James Lu wrote: > This list IS hard for newcomers. I wish there was one place where I > could read up on how to not feel like a noob. It has become unfashionable to link to this, because it is allegedly too elitest and unfriendly and not welcoming enough, but I still think it is extremely valuable: http://www.catb.org/esr/faqs/smart-questions.html (Its also somewhat unpopular because the maintainer has become something of a politically Right-wing extremist.) If you think of *proposals* as a kind of question: "What are the Pros and Cons of this suggestion?" rather than "We must do this. I have spoken, make it so!" then the Smart Questions document is relevant. Do your research first. What have you tried? Have you tried to knock holes in your own proposal or are you so excited by the Pros that you are blind to the Cons? What do other languages do? Do they differ from Python in ways which matter to your proposal? Did you make even a feeble attempt to search the archives, Stackoverflow, etc, or just post the first ill-formed thought that came to your mind? If your proposal been asked before, unless you are bringing something new to the discussion, don't waste everyone's time covering old ground. -- Steven From tjreedy at udel.edu Sat Feb 2 19:37:56 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 2 Feb 2019 19:37:56 -0500 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190202131334.oca4kojgegyxuh73@phdru.name> References: <19e0bc1f-1e0f-82fd-293b-e338773761ea@gmail.com> <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> Message-ID: On 2/2/2019 8:13 AM, Oleg Broytman wrote: > On Fri, Feb 01, 2019 at 08:40:22PM -0500, Terry Reedy wrote: >> On 2/1/2019 3:31 PM, Oleg Broytman wrote: >> >>> Python REPL is missing the following batteries: >> >> That is why, on Windows, I nearly always use IDLE. I believe this was Chris, not me. >> >>> * Persistent history; >> >> IDLE's Shell history persists across restarts (which >> are not available is the standard shell). I cannot remember wanting history >> saved between IDLE sessions. I also cannot remember seeing a request for >> this feature. If I want a sequence of commands saved, I copy them into an >> editor window and save in a named file. >> >>> * Syntax highlighting; To do this correctly requires a separate programmable repl that sees each character as it is entered. To me, this is as useful in the repl as in an editor. >> IDLE does this. >> >>> * Clear separation (using, for example, different colors) >>> between input, output and errors; >> >> IDLE does this. > > For the question "Does Python REPL need more batteries?" is your > answer "No, just point people to IDLE"? If one want these batteries *today*, that is one sane answer, especially on Windows and, it seems so far, Mac. > If it is - well, I disagree. I implemented a lot of enhancements for > REPL myself, and I don't like and avoid GUI programs. Whereas, in spite of (or perhaps because of) possibly being older than you, I am the opposite. Many beginners, even after multiple college CS classes, have never used a TUI (text user interface) program like Command Prompt before encountering Python and wanting to do something that requires the TUI, such as using pip. Anti-GUI attitudes make Python harder to use for many people. Pip, for instance, desperately needs a GUI front end. I believe that PIP problems are the most common Python question on StackOverflow. However, the pip people will not write one and I was prohibited from adding one to the stdlib. >>> * Paging of very long output/errors. >> >> Help output *is* paged in the standard shell. For comparison with IDLE, for >> issue 35855, I tried out help(tkinter) in standard Python on both Windows >> and Mac. For the most part, I found the pagers to be somewhat obnoxious and >> deficient*. Except for one thing that I want to fix, paging up and down a >> window with the standard PageUp and PageDown keys, as in IDLE, is easier and >> better. And it is not limited > > I found pager ``less`` quite good. I configured it in a complex way, > learned to use it and use in many different programs, not only Python. > >> * Windows Console holds a maximum of 9999 characters, with the default being >> 300, at least for Command Prompt. The less pager, at least on Mac, when >> invoked by help when running Python in Terminal, displays the paged output >> in a separate window. When less is exited, the window closes and the paged >> output *disappears*. I don't know what less configuration one can do on Mac, but its default of erasing help output before one writes the statement one wanted help for is quite bad to me. > You left out what I think is a very important 'battery': >> * Works with Python statements instead of physical lines of text. >> As I discussed elsewhere, this includes editing entire multiline statements >> before submitting and storing and retrieving complete statements to and from >> the history list. > > Yep, would be nice to have. Bash implements it somehow. Mac terminal does not. >> Here is another: >> * Clicking on a traceback item can open the file in an editor at the >> indicated line. > > That would be too much. Now that I am used to this, I consider it essential. > Requires a traceback-sensitive pager. It require something that can match the regex "File ([~,]*), line ([0-9]*)," to a selected line or the one above it and pass the captured file name and line number (if successful) to something that can open the file at the line). > Also > not very useful for situations where developer works on one host and > runs programs on another (containers/virtual machines/remote hosts are > widely used these days). I and many other people edit and run on the same machine. However, editing and running on different machines is to me an argument for keeping the UI separate from the execution binary. What matters is where the user interface presenting the traceback is, not where the program was run. IDLE runs user code in a separate process, with a socket and rpc connection to the GUI. It could potentially run the separate process in a separate machine. IDLE compiles user code in the GUI before sending the code object to the execution process. The 'instant' syntax check would be even more relatively useful if execution were on a remote machine, with the attendant delay. Another IDLE feature I miss in the default REPL is smart auto-indentation. This includes following some PEP 8 recommendations for non-significant indentation of continuation lines. Thinking about it, the IDLE code either is or could be independent of the tkinter text widget. With a little work, it could be moved into the code module for use by InteractiveInterpreter, which IDLE uses, and by anyone else, including, maybe, python itself. Since it enforces a particular style, it would have to be optional at least for InteractiveInterpreter and python. -- Terry Jan Reedy From benrudiak at gmail.com Sat Feb 2 20:00:28 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Sat, 2 Feb 2019 17:00:28 -0800 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190202064537.GI1834@ando.pearwood.info> References: <20190202064537.GI1834@ando.pearwood.info> Message-ID: Note: none of the following is an endorsement of the r/python_ideas idea. I'm just responding point-by-point to what you wrote. On Fri, Feb 1, 2019 at 10:47 PM Steven D'Aprano wrote: > - I can have as many email identities as I like; I can only have one > Reddit identity at a time. Do you mean because your browser doesn't support per-window or per-tab cookie jars? I'm pretty sure there are browsers that do. (I use multiple instances of the same browser with different home directories to solve this general problem, but I think there are other solutions.) Also, many clients (including RES in a browser) support switching accounts by choosing from a drop-down list. > If I want to keep my Reddit persona seperate from my Python persona, I > need to create multiple accounts (possibly violating the terms of > service?) and remember to log out of one and into the other. It isn't a violation of the TOS and it's extremely common and people are open about it. It is a TOS violation to, for instance, up/downvote the same post/comment with two of your accounts. > - Too difficult (impossible?) to keep local human-readable copies of > either the discussion thread, or even your own posts. I agree the Reddit client situation is pretty sad compared to the email client situation, but non-browser clients do exist. You don't have to use Reddit in a browser. RES lets you save things locally, but you are still stuck viewing them in a browser. > - I have to explicitly go to the site to see what is happening, rather > than have the posts automatically arrive in my inbox. Well, you can get an RSS feed of any subreddit or comment thread and stick that in your email client. It's not perfect I agree. >From another of your messages: > Core developer Brett Cannon has taken up editing other people's comments > on github if he doesn't approve of their tone. > [...] > Github (currently) provides the full history of edits to each post. > Reddit just has a flag that shows you whether a post was edited or not. > Isn't technology wonderful? Reddit doesn't allow anyone but the original user to edit posts or comments. Moderators (ordinary users who are selected per subreddit like IRC ops) can only remove the entire text of a comment (or text post) and put "[removed]" in its place. They can also make posts no longer appear on the subreddit, but they continue to be viewable if you have the direct url. There was a scandal in which a Reddit co-founder admitted to editing someone's comment. I think he was able to do that because he had direct database access. If someone has direct database access then of course a full edit history won't help since you can bypass that along with everything else. I am definitely a fan of the distributed nature of email. However, a rogue admin of python.org or their registrar or ISP or some Internet switch could alter emails to this list without leaving any edit history. Proper authentication could solve a lot of that, but as long as we're dreaming, it's only fair to make Reddit distributed and not-for-profit too. From greg.ewing at canterbury.ac.nz Sat Feb 2 20:34:58 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 03 Feb 2019 14:34:58 +1300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <0d545af3-3fbf-adea-f7b7-2916003fc723@mrabarnett.plus.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <20190202085835.GK1834@ando.pearwood.info> <0d545af3-3fbf-adea-f7b7-2916003fc723@mrabarnett.plus.com> Message-ID: <5C564542.2060705@canterbury.ac.nz> MRAB wrote: > Well, if we were using an English prefix, wouldn't it be "unhomogeneous"? If we're sticking with Greek it would have to be something like "anhomogeneous". -- Greg From phd at phdru.name Sat Feb 2 20:52:31 2019 From: phd at phdru.name (Oleg Broytman) Date: Sun, 3 Feb 2019 02:52:31 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> Message-ID: <20190203015231.4jojun5fvkxw5a63@phdru.name> On Sat, Feb 02, 2019 at 07:37:56PM -0500, Terry Reedy wrote: > On 2/2/2019 8:13 AM, Oleg Broytman wrote: > > > IDLE does this. > > > > For the question "Does Python REPL need more batteries?" is your > > answer "No, just point people to IDLE"? > > If one want these batteries *today*, that is one sane answer, especially on > Windows and, it seems so far, Mac. > > > If it is - well, I disagree. I implemented a lot of enhancements for > > REPL myself, and I don't like and avoid GUI programs. > > Whereas, in spite of (or perhaps because of) possibly being older than you, Oh, "my beard is longer than your" game! :-))) I'm 51 y.o. But I always was like that. When all sane people were switching from DOS to Windows 3.0 I switched to Unix. First, BSD/OS, later SunOS, later FreeBSD, after that Linux, Linux, Linux. At DOS times I was writing huge .bat-files using all possible tools I can collect in pre-Internet era. Small utilities, alternative command line interpreters (4DOS), .bat compilers (turbobat). I tolerated TUI but hated GUI even then. Switching to shell scripting was pretty natural for me with awk/find/grep/sed/etc replacing all those tools. > Anti-GUI attitudes make Python harder to use for many people. Pip, for > instance, desperately needs a GUI front end. For me it's hard to believe ``pip`` needs any UI. I run ``pip`` in command line, in scripts and at remote servers, often completely unattended (Travis CI and AppVeyor, e.g.) I don't see how I'd use an UI. > I believe that PIP problems > are the most common Python question on StackOverflow. Problems - yes. But not because it lacks an UI. I read SO every day for a few years now and answer questions every few days. I don't remember people ever asked about any UI for pip. pip problems, as far as I can recollect the problems, are: * SSL; recently pypi.org and github.com switched to TLS1.2-only and the change broke a lot of sites where people still run CentOS 5 and other old Python versions without any possibility of upgrading. * A few pythons at the host: run ``pip install module``, ``import module``, got ``ImportError/NoModuleFoundError`` because ``pip`` and ``import`` are ran with 2 different pythons. * Incompatible upgrades: ``pip`` was upgraded but the user didn't get that it was ``/usr/bin/pip`` that was upgraded and ``/usr/local/bin/pip`` is now outdated but is found first in ``$PATH``. Hence the error ``AttributeError: main``. * The absence of a compiler on Windows (or a wrong version of it) to install a C extension without a binary wheel. * Offline installation. Downloading binary wheels for a different platform (different from the host where ``pip`` is running). > -- > Terry Jan Reedy Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From mertz at gnosis.cx Sat Feb 2 20:54:12 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 20:54:12 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: Here is a very toy proof-of-concept: >>> from vector import Vector >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >>> v = Vector(l) >>> v >>> v.strip().lower().replace('a','X') >>> vt = Vector(tuple(l)) >>> vt >>> vt.lower().replace('o','X') My few lines are at https://github.com/DavidMertz/stringpy One thing I think I'd like to be different is to have some way of accessing EITHER the collection being held OR each element. So now I just get: >>> v.__len__() Yes, that's an ugly spelling of `len(v)`, but let's bracket that for the moment. It would be nice also to be able to ask "what's the length of the vector, in a non-vectorized way" (i.e. 12 in this case). Maybe some naming convention like: >>> v.collection__len__() 12 This last is just a possible behavior, not in the code I just uploaded. On Sat, Feb 2, 2019 at 6:47 PM Chris Angelico wrote: > On Sun, Feb 3, 2019 at 10:36 AM Ben Rudiak-Gould > wrote: > > > > On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker > wrote: > >> > >> a_list_of_strings.strip().lower().title() > >> > >> is a lot nicer than: > >> > >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in > a_list_of_strings])] > >> > >> or > >> > >> list(map(str.title, (map(str.lower, (map(str.strip, > a_list_of_strings)))) # untested > > > > In this case you can write > > > > [s.strip().lower().title() for s in a_list_of_strings] > > What if it's a more complicated example? > > len(sorted(a_list_of_strings.casefold())[:100]) > > where the len() is supposed to give back a list of the lengths of the > first hundred strings, sorted case insensitively? (Okay so it's a > horrible contrived example. Bear with me.) > > With current syntax, this would need multiple map calls or comprehensions: > > [len(s) for s in sorted(s.casefold() for s in a_list_of_strings)[:100]] > > (Better examples welcomed.) > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phd at phdru.name Sat Feb 2 20:59:00 2019 From: phd at phdru.name (Oleg Broytman) Date: Sun, 3 Feb 2019 02:59:00 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190203015231.4jojun5fvkxw5a63@phdru.name> References: <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> <20190203015231.4jojun5fvkxw5a63@phdru.name> Message-ID: <20190203015900.an7secxw4sxmztu2@phdru.name> On Sun, Feb 03, 2019 at 02:52:31AM +0100, Oleg Broytman wrote: > On Sat, Feb 02, 2019 at 07:37:56PM -0500, Terry Reedy wrote: > > On 2/2/2019 8:13 AM, Oleg Broytman wrote: > > > > IDLE does this. > > > > > > For the question "Does Python REPL need more batteries?" is your > > > answer "No, just point people to IDLE"? > > > > If one want these batteries *today*, that is one sane answer, especially on > > Windows and, it seems so far, Mac. > > > > > If it is - well, I disagree. I implemented a lot of enhancements for > > > REPL myself, and I don't like and avoid GUI programs. > > > > Whereas, in spite of (or perhaps because of) possibly being older than you, > > Oh, "my beard is longer than your" game! :-))) I'm 51 y.o. But I > always was like that. When all sane people were switching from DOS to > Windows 3.0 I switched to Unix. First, BSD/OS, later SunOS, later > FreeBSD, after that Linux, Linux, Linux. At DOS times I was writing huge > .bat-files using all possible tools I can collect in pre-Internet era. > Small utilities, alternative command line interpreters (4DOS), .bat > compilers (turbobat). I tolerated TUI but hated GUI even then. > Switching to shell scripting was pretty natural for me with > awk/find/grep/sed/etc replacing all those tools. > > > Anti-GUI attitudes make Python harder to use for many people. Pip, for > > instance, desperately needs a GUI front end. > > For me it's hard to believe ``pip`` needs any UI. I run ``pip`` in > command line, in scripts and at remote servers, often completely > unattended (Travis CI and AppVeyor, e.g.) I don't see how I'd use an UI. > > > I believe that PIP problems > > are the most common Python question on StackOverflow. > > Problems - yes. But not because it lacks an UI. I read SO every day > for a few years now and answer questions every few days. I don't > remember people ever asked about any UI for pip. pip problems, as far as > I can recollect the problems, are: > > * SSL; recently pypi.org and github.com switched to TLS1.2-only > and the change broke a lot of sites where people still run > CentOS 5 and other old Python versions without any possibility > of upgrading. > * A few pythons at the host: run ``pip install module``, > ``import module``, got ``ImportError/NoModuleFoundError`` because > ``pip`` and ``import`` are ran with 2 different pythons. > * Incompatible upgrades: ``pip`` was upgraded but the user didn't get > that it was ``/usr/bin/pip`` that was upgraded and > ``/usr/local/bin/pip`` is now outdated but is found first in > ``$PATH``. Hence the error ``AttributeError: main``. > * The absence of a compiler on Windows (or a wrong version of it) > to install a C extension without a binary wheel. > * Offline installation. Downloading binary wheels for a different > platform (different from the host where ``pip`` is running). Sorry, was not completely clear here: * Downloading the tree of dependencies (binary wheels or source distributions if there are no binary wheels) for a different platform. > > -- > > Terry Jan Reedy Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From mertz at gnosis.cx Sat Feb 2 21:03:03 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 21:03:03 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: Slightly more on my initial behavior: >>> Vector({1:2,3:4}) TypeError: Ambiguity vectorizing a map, perhaps try it.keys(), it.values(), or it.items() >>> Vector(37) TypeError: Vector can only be initialized with an iterable >>> Vector("hello") I'm wondering if maybe making a vector out of a scalar should simply be a length-one vector. What do you think? Also, should a single string be treated like a vector of characters or like a scalar? It feels kinda pointless to make a vector of characters since I cannot think of anything it would do better than a plain string already does (largely just the same thing slower). On Sat, Feb 2, 2019 at 8:54 PM David Mertz wrote: > Here is a very toy proof-of-concept: > > >>> from vector import Vector > >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() > >>> v = Vector(l) > >>> v > 'Oct', 'Nov', 'Dec']> > >>> v.strip().lower().replace('a','X') > 'oct', 'nov', 'dec']> > >>> vt = Vector(tuple(l)) > >>> vt > 'Oct', 'Nov', 'Dec')> > >>> vt.lower().replace('o','X') > 'Xct', 'nXv', 'dec')> > > > My few lines are at https://github.com/DavidMertz/stringpy > > One thing I think I'd like to be different is to have some way of > accessing EITHER the collection being held OR each element. So now I just > get: > > >>> v.__len__() > > > > Yes, that's an ugly spelling of `len(v)`, but let's bracket that for the > moment. It would be nice also to be able to ask "what's the length of the > vector, in a non-vectorized way" (i.e. 12 in this case). Maybe some naming > convention like: > > >>> v.collection__len__() > 12 > > > This last is just a possible behavior, not in the code I just uploaded. > > > On Sat, Feb 2, 2019 at 6:47 PM Chris Angelico wrote: > >> On Sun, Feb 3, 2019 at 10:36 AM Ben Rudiak-Gould >> wrote: >> > >> > On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker >> wrote: >> >> >> >> a_list_of_strings.strip().lower().title() >> >> >> >> is a lot nicer than: >> >> >> >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in >> a_list_of_strings])] >> >> >> >> or >> >> >> >> list(map(str.title, (map(str.lower, (map(str.strip, >> a_list_of_strings)))) # untested >> > >> > In this case you can write >> > >> > [s.strip().lower().title() for s in a_list_of_strings] >> >> What if it's a more complicated example? >> >> len(sorted(a_list_of_strings.casefold())[:100]) >> >> where the len() is supposed to give back a list of the lengths of the >> first hundred strings, sorted case insensitively? (Okay so it's a >> horrible contrived example. Bear with me.) >> >> With current syntax, this would need multiple map calls or comprehensions: >> >> [len(s) for s in sorted(s.casefold() for s in a_list_of_strings)[:100]] >> >> (Better examples welcomed.) >> >> ChrisA >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Sat Feb 2 21:59:36 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sun, 3 Feb 2019 02:59:36 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: <880f0c5f-f297-a25a-d881-664e2cd12958@mrabarnett.plus.com> On 2019-02-03 01:54, David Mertz wrote: > Here is a very toy proof-of-concept: > > >>> from vector import Vector > >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() > >>> v = Vector(l) > >>> v > 'Sep', 'Oct', 'Nov', 'Dec']> > >>> v.strip().lower().replace('a','X') > 'sep', 'oct', 'nov', 'dec']> > >>> vt = Vector(tuple(l)) > >>> vt > 'Sep', 'Oct', 'Nov', 'Dec')> > >>> vt.lower().replace('o','X') > 'sep', 'Xct', 'nXv', 'dec')> > > > My few lines are at https://github.com/DavidMertz/stringpy > > One thing I think I'd like to be different is to have some way of > accessing EITHER the collection being held OR each element.? So now I > just get: > > >>> v.__len__() > > > > Yes, that's an ugly spelling of `len(v)`, but let's bracket that for the > moment.? It would be nice also to be able to ask "what's the length of > the vector, in a non-vectorized way" (i.e. 12 in this case).? Maybe some > naming convention like: > > >>> v.collection__len__() > 12 > > > This last is just a possible behavior, not in the code I just uploaded. > Perhaps a reserved attribute that let's you refer to the vector itself instead of its members, e.g. '.self'? >>> len(v) >>> len(v.self) 12 >>> v[1 : ] >>> v.self[1 : ] > > On Sat, Feb 2, 2019 at 6:47 PM Chris Angelico > wrote: > > On Sun, Feb 3, 2019 at 10:36 AM Ben Rudiak-Gould > > wrote: > > > > On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker > > wrote: > >> > >> a_list_of_strings.strip().lower().title() > >> > >> is a lot nicer than: > >> > >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in > a_list_of_strings])] > >> > >> or > >> > >> list(map(str.title, (map(str.lower, (map(str.strip, > a_list_of_strings)))) # untested > > > > In this case you can write > > > >? ? ?[s.strip().lower().title() for s in a_list_of_strings] > > What if it's a more complicated example? > > len(sorted(a_list_of_strings.casefold())[:100]) > > where the len() is supposed to give back a list of the lengths of the > first hundred strings, sorted case insensitively? (Okay so it's a > horrible contrived example. Bear with me.) > > With current syntax, this would need multiple map calls or > comprehensions: > > [len(s) for s in sorted(s.casefold() for s in a_list_of_strings)[:100]] > > (Better examples welcomed.) > From mertz at gnosis.cx Sat Feb 2 22:02:37 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 22:02:37 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: Trying to make iterators behave in a semi-nice way also. I kinda like this (example remains silly, but it shows idea). >>> for n, mon in enumerate(vi.upper().replace('J','_').title()): ... print(mon) ... if n>3: break ... ... _An Feb Mar Apr May >>> vi > >>> list(vi) ['Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'] >>> vi > >>> list(vi) [] On Sat, Feb 2, 2019 at 9:03 PM David Mertz wrote: > Slightly more on my initial behavior: > > >>> Vector({1:2,3:4}) > TypeError: Ambiguity vectorizing a map, perhaps try it.keys(), > it.values(), or it.items() > > >>> Vector(37) > TypeError: Vector can only be initialized with an iterable > > >>> Vector("hello") > > > > I'm wondering if maybe making a vector out of a scalar should simply be a > length-one vector. What do you think? > > Also, should a single string be treated like a vector of characters or > like a scalar? It feels kinda pointless to make a vector of characters > since I cannot think of anything it would do better than a plain string > already does (largely just the same thing slower). > > On Sat, Feb 2, 2019 at 8:54 PM David Mertz wrote: > >> Here is a very toy proof-of-concept: >> >> >>> from vector import Vector >> >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >> >>> v = Vector(l) >> >>> v >> > 'Sep', 'Oct', 'Nov', 'Dec']> >> >>> v.strip().lower().replace('a','X') >> > 'sep', 'oct', 'nov', 'dec']> >> >>> vt = Vector(tuple(l)) >> >>> vt >> > 'Sep', 'Oct', 'Nov', 'Dec')> >> >>> vt.lower().replace('o','X') >> > 'sep', 'Xct', 'nXv', 'dec')> >> >> >> My few lines are at https://github.com/DavidMertz/stringpy >> >> One thing I think I'd like to be different is to have some way of >> accessing EITHER the collection being held OR each element. So now I just >> get: >> >> >>> v.__len__() >> >> >> >> Yes, that's an ugly spelling of `len(v)`, but let's bracket that for the >> moment. It would be nice also to be able to ask "what's the length of the >> vector, in a non-vectorized way" (i.e. 12 in this case). Maybe some naming >> convention like: >> >> >>> v.collection__len__() >> 12 >> >> >> This last is just a possible behavior, not in the code I just uploaded. >> >> >> On Sat, Feb 2, 2019 at 6:47 PM Chris Angelico wrote: >> >>> On Sun, Feb 3, 2019 at 10:36 AM Ben Rudiak-Gould >>> wrote: >>> > >>> > On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker >>> wrote: >>> >> >>> >> a_list_of_strings.strip().lower().title() >>> >> >>> >> is a lot nicer than: >>> >> >>> >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in >>> a_list_of_strings])] >>> >> >>> >> or >>> >> >>> >> list(map(str.title, (map(str.lower, (map(str.strip, >>> a_list_of_strings)))) # untested >>> > >>> > In this case you can write >>> > >>> > [s.strip().lower().title() for s in a_list_of_strings] >>> >>> What if it's a more complicated example? >>> >>> len(sorted(a_list_of_strings.casefold())[:100]) >>> >>> where the len() is supposed to give back a list of the lengths of the >>> first hundred strings, sorted case insensitively? (Okay so it's a >>> horrible contrived example. Bear with me.) >>> >>> With current syntax, this would need multiple map calls or >>> comprehensions: >>> >>> [len(s) for s in sorted(s.casefold() for s in a_list_of_strings)[:100]] >>> >>> (Better examples welcomed.) >>> >>> ChrisA >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> Keeping medicines from the bloodstreams of the sick; food >> from the bellies of the hungry; books from the hands of the >> uneducated; technology from the underdeveloped; and putting >> advocates of freedom in prisons. Intellectual property is >> to the 21st century what the slave trade was to the 16th. >> > > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Sat Feb 2 22:02:59 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sun, 3 Feb 2019 03:02:59 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> Message-ID: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> On 2019-02-03 02:03, David Mertz wrote: > Slightly more on my initial behavior: > > >>> Vector({1:2,3:4}) > TypeError: Ambiguity vectorizing a map, perhaps try it.keys(), > it.values(), or it.items() > > >>> Vector(37) > TypeError: Vector can only be initialized with an iterable > > >>> Vector("hello") > > > > I'm wondering if maybe making a vector out of a scalar should simply be > a length-one vector. What?do you think? > > Also, should a single string be treated like a vector of characters or > like a scalar? It feels kinda pointless to make a vector of characters > since I cannot think of anything it would do better than a plain string > already does (largely just the same thing slower). > [snip] I think it should follow the pre-existing behaviour of list, set, tuple, etc. >>> Vector("hello") Why is it pointless for a vector, but not for a list? From mertz at gnosis.cx Sat Feb 2 22:07:48 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 22:07:48 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <880f0c5f-f297-a25a-d881-664e2cd12958@mrabarnett.plus.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <880f0c5f-f297-a25a-d881-664e2cd12958@mrabarnett.plus.com> Message-ID: On Sat, Feb 2, 2019 at 10:00 PM MRAB wrote: > Perhaps a reserved attribute that let's you refer to the vector itself > instead of its members, e.g. '.self'? > > >>> len(v) > > >>> len(v.self) > 12 > I like that! But I'm not sure if '.self' is misleading. I use an attribute called '._it' already that does exactly this. But since we're asking the length of the list or tuple or set or deque or etc that the Vector wraps, does it feel like it would be deceptive to call them all '.self'? I'm really not sure. I could just rename '._it' to '.self' and get the behavior you show (well, I still need a little checking whether the thing wrapped is a collection or an iterator ... I guess a '.self' property. Or some other name to do that). You remind me that I need to at .__getitem__() too so I can slice and index Vectors. But I know how to do that easily enough. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sat Feb 2 22:18:26 2019 From: mertz at gnosis.cx (David Mertz) Date: Sat, 2 Feb 2019 22:18:26 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: > > I think it should follow the pre-existing behaviour of list, set, tuple, > etc. > > >>> Vector("hello") > > I try to keep the underlying datatype of the wrapped collection as much as possible. Casting a string to a list changes that. >>> Vector(d) >>> Vector(tuple(d)) >>> Vector(set(d)) >>> from collections import deque >>> Vector(deque(d)) Strings are already a Collection, there is not firm need cast them to a list to live inside a Vector. I like the idea of maintaining the original type if someone wants it back later (possibly after transformations of the values). Why is it pointless for a vector, but not for a list? > I guess it really isn't. I was thinking of just .upper() and .lower() where upper/lower-casing each individual letter is the same as doing so to the whole string. But for .replace() or .count() or .title() or .swapcase() the meaning is very different if it is letter-at-a-time. I guess a string gets unstringified pretty quickly no matter what though. E.g. this seems like right behavior once we transform something: >>> vstr = Vector('Monday') >>> vstr >>> vstr.upper() I dunno... I suppose I *could* do `self._it = "".join(self._it)` whenever I do a transform on a string to keep the underlying iterable as a string. But the point of a Vector really is sequences of strings not sequences of characters. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sun Feb 3 03:06:49 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 19:06:49 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: <20190203080648.GU1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 10:57:40AM -0500, James Lu wrote: > It?s very demotivating to hear just negative feedback on this list. > > Was starting this thread useful for y?all? Do you want an honest answer, or positive feedback? ("It was great!") Personally, no, it wasn't useful for me. It was a major time-sink to read a large number of emails mostly arguing about the pros and cons of email versus web forums, the value of Like buttons, and whether or not you can access Reddit outside of a browser. But when you get down to the fundamentals, none of these matter for effective communication. We can write lazy, confusing, knee-jerk posts on Reddit just as easily as via email. (If anything, the easier the medium for communication, the lazier, more confusing and more knee-jerk we will be.) As far as I can tell, I was the only person who actually tried to provide some concrete suggestions for communicating clearly. Although it is still only early days, maybe others will give their own suggestions over the next few days. (Come one guys, don't let me be the only one answering James' direct question.) Apologies if I missed other people's insights on clear communication. I did go back through the thread looking, but perhaps I didn't look closely enough. -- Steven From rosuav at gmail.com Sun Feb 3 03:40:37 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sun, 3 Feb 2019 19:40:37 +1100 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190203080648.GU1834@ando.pearwood.info> References: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> <20190203080648.GU1834@ando.pearwood.info> Message-ID: On Sun, Feb 3, 2019 at 7:07 PM Steven D'Aprano wrote: > > On Sat, Feb 02, 2019 at 10:57:40AM -0500, James Lu wrote: > > It?s very demotivating to hear just negative feedback on this list. > > > > Was starting this thread useful for y?all? > > Do you want an honest answer, or positive feedback? ("It was great!") > > Personally, no, it wasn't useful for me. > > It was a major time-sink to read a large number of emails mostly arguing > about the pros and cons of email versus web forums, the value of Like > buttons, and whether or not you can access Reddit outside of a browser. > But when you get down to the fundamentals, none of these matter for > effective communication. We can write lazy, confusing, knee-jerk posts > on Reddit just as easily as via email. > > (If anything, the easier the medium for communication, the lazier, more > confusing and more knee-jerk we will be.) > > As far as I can tell, I was the only person who actually tried to > provide some concrete suggestions for communicating clearly. Although it > is still only early days, maybe others will give their own suggestions > over the next few days. > > (Come one guys, don't let me be the only one answering James' direct > question.) Sorry Steve, but I didn't answer his question because this whole thread has become nothing but noise, and I'm trying not to contribute any further to it. Which I'm doing here, by saying that no, it was not a useful thread. Mea culpa. ChrisA From ricocotam at gmail.com Sun Feb 3 03:54:09 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sun, 3 Feb 2019 09:54:09 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: Nice that you implemented it ! I think all the issues you have right now would go of using another operation. I proposed the @ notation that is clear and different from everything else, plus the operator is called "matmul" so it completely makes sense. The the examples would be : >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >>> v = Vector(l) >>> len(v) 12 >>> v @ len >>> list(v) ["Jan", "Feb", "Mar", "Apr", "May", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"] >>> v @ list >> from functools import partial >>> import operator >>> v[1:] >>> my_slice = slice(1, None, None) >>> indexing_operation = partial(operator.getitem(my_slice)) >>> v @ indexing_operation That little example shows the need of configuring functions so they only accept on argument. It's actually not a new problem since map have the same "issue". A vector of one element should still be a vector, as a list/tuple/dict of one element is a list/tuple/dict, imo. I suggested Vector objects to inherit from lists, and therefore be iterables. It would be handy to iterator over its elements and simple loops, maps, etc, should still be available to them. It might be clearer to use "old" notations for some operations. About the `Vector("A Super String")`, if we want it to be a vector of one element, we should use `Vector(["A Super String"])`, as we would do in any other function using an iterable as input. Side Note : Honestly, I don't think it's the good thread to debate whether we should use ["in", "un", "an", "non"] - homogeneous or heterogeneous. As long as it's clear, does it matter ? Le dim. 3 f?vr. 2019 ? 04:19, David Mertz a ?crit : > I think it should follow the pre-existing behaviour of list, set, tuple, >> etc. >> >> >>> Vector("hello") >> >> > > I try to keep the underlying datatype of the wrapped collection as much > as possible. Casting a string to a list changes that. > > >>> Vector(d) > > >>> Vector(tuple(d)) > > >>> Vector(set(d)) > > >>> from collections import deque > >>> Vector(deque(d)) > > > > Strings are already a Collection, there is not firm need cast them to a > list to live inside a Vector. I like the idea of maintaining the original > type if someone wants it back later (possibly after transformations of the > values). > > Why is it pointless for a vector, but not for a list? >> > > I guess it really isn't. I was thinking of just .upper() and .lower() > where upper/lower-casing each individual letter is the same as doing so to > the whole string. But for .replace() or .count() or .title() or > .swapcase() the meaning is very different if it is letter-at-a-time. > > I guess a string gets unstringified pretty quickly no matter what though. > E.g. this seems like right behavior once we transform something: > > >>> vstr = Vector('Monday') > >>> vstr > > >>> vstr.upper() > > > > I dunno... I suppose I *could* do `self._it = "".join(self._it)` whenever > I do a transform on a string to keep the underlying iterable as a string. > But the point of a Vector really is sequences of strings not sequences of > characters. > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Sun Feb 3 04:04:17 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sun, 3 Feb 2019 10:04:17 +0100 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> <20190203080648.GU1834@ando.pearwood.info> Message-ID: > Was starting this thread useful for y?all? For now no, but it could. There's a tradeoff to have between the advantages of new social medias and their disadvantages. Since it's 50/50 or even 70 bad, 30 why not, we will probably keep mails. But some points have been said and were important. I especially think about the message of Steve and some suggestions about welcoming new-comers with a message to help them a bit. Last thing that was important to me and non-english speakers was to say it was not always easy to understand, despite we speak well and that some behaviors might just be a mis-understanding rather than something else. Le dim. 3 f?vr. 2019 ? 09:41, Chris Angelico a ?crit : > On Sun, Feb 3, 2019 at 7:07 PM Steven D'Aprano > wrote: > > > > On Sat, Feb 02, 2019 at 10:57:40AM -0500, James Lu wrote: > > > It?s very demotivating to hear just negative feedback on this list. > > > > > > Was starting this thread useful for y?all? > > > > Do you want an honest answer, or positive feedback? ("It was great!") > > > > Personally, no, it wasn't useful for me. > > > > It was a major time-sink to read a large number of emails mostly arguing > > about the pros and cons of email versus web forums, the value of Like > > buttons, and whether or not you can access Reddit outside of a browser. > > But when you get down to the fundamentals, none of these matter for > > effective communication. We can write lazy, confusing, knee-jerk posts > > on Reddit just as easily as via email. > > > > (If anything, the easier the medium for communication, the lazier, more > > confusing and more knee-jerk we will be.) > > > > As far as I can tell, I was the only person who actually tried to > > provide some concrete suggestions for communicating clearly. Although it > > is still only early days, maybe others will give their own suggestions > > over the next few days. > > > > (Come one guys, don't let me be the only one answering James' direct > > question.) > > Sorry Steve, but I didn't answer his question because this whole > thread has become nothing but noise, and I'm trying not to contribute > any further to it. > > Which I'm doing here, by saying that no, it was not a useful thread. Mea > culpa. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sun Feb 3 06:24:12 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 3 Feb 2019 22:24:12 +1100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: References: <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> Message-ID: <20190203112411.GV1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 07:37:56PM -0500, Terry Reedy wrote: [...] > >>>* Syntax highlighting; > > To do this correctly requires a separate programmable repl that sees > each character as it is entered. To me, this is as useful in the repl > as in an editor. That's an ambiguous sentence. It could mean that syntax highlighting in both are as useful as a screen door on a submarine :-) I don't know how you use the REPL, but for me, highlighting in the REPL is much less useful because I'm not looking at large chunks of code at a time. If it is more than, oh, two or three lines, it is too big to be editing in the clunky editing environment of a REPL and I'll use an editor to read/edit the code. > Anti-GUI attitudes make Python harder to use for many people. Pip, for > instance, desperately needs a GUI front end. I believe that PIP > problems are the most common Python question on StackOverflow. However, > the pip people will not write one and I was prohibited from adding one > to the stdlib. Did you put it on PyPI? That's the usual suggestion for something that might be useful but isn't believed to be needed for the stdlib. As Nick said, Rather than "rejected" per se, I've closed this as "postponed" https://bugs.python.org/issue27051#msg286634 https://summerofcode.withgoogle.com/archive/2016/projects/5063140450500608/ [...] > I don't know what less configuration one can do on Mac, but its default > of erasing help output before one writes the statement one wanted help > for is quite bad to me. I'd like to see the help pager code made into a public API, and help itself made configurable by the user to choose a pager (auto-detecting a pager by default, as it does now). That would allow people to choose whichever pager works best for them -- possibly including a seperate GUI window which they could leave open all the time. > >You left out what I think is a very important 'battery': > >>* Works with Python statements instead of physical lines of text. > >>As I discussed elsewhere, this includes editing entire multiline > >>statements > >>before submitting and storing and retrieving complete statements to and > >>from > >>the history list. > > > > Yep, would be nice to have. Bash implements it somehow. > > Mac terminal does not. If you are running a sufficiently recent bash and readline is supported, it should support any feature the POSIX bash supports, regardless of the OS or the terminal. (Although I think readline on Mac is slightly different from other Unix systems? And maybe less functional?) I'm not sure what multiline editing is being referred to above. I personally don't know of one in bash. It may be that you have to turn the feature on -- by default, bash ships with a fair amount of stuff turned off, and the rest hidden behind cryptic keystroke commands. One readline feature I know of which I would love to see supported in the REPL is the "execute and next line" command. On my bash system, it is Ctrl-O. What it does: - use the up-arrow to move through the history to the line you want to execute; - type Ctrl-O to execute that line; - the *next* line is automatically loaded, ready to be executed. E.g. suppose my history consists of five lines: 1: print('hello') 2: def spam(): 3: x = 1 4: return x + 1 5: foo = spam() and I want to re-load the spam function (perhaps after editing it) in the REPL. From a bare prompt, I can: * hit UP-ARROW four times to get to line 2 of the history, then ENTER; * this pushes a new line into the history; * hit UP-ARROW four times again to get to line 3, then ENTER; * hit UP-ARROW four more times to get to line 4, then ENTER. With execute-and-next-line, I could: * hit UP-ARROW four times to get to line 2 of the history, then Ctrl-O; * this loads line 3, so I can immediately hit Ctrl-O; * this loads line 4, so I can immediately hit ENTER. Much easier to re-execute or edit a multiline block! As far as I can tell, it is impossible to add this feature to the REPL from pure Python (corrections welcome!) but I imagine it would be something IDLE could do. -- Steve From p.f.moore at gmail.com Sun Feb 3 07:40:37 2019 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 3 Feb 2019 12:40:37 +0000 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: On Sat, 2 Feb 2019 at 23:38, James Lu wrote: > > It?s very demotivating to hear just negative feedback on this list. > > Was starting this thread useful for y?all? In the interests of clear communication, no it wasn't. In the interests of trying not to be *too* demotivating, the reason is that it was far too general a question, and it was almost entirely about how people behave, which is a sensitive topic, and not one that's well suited to the medium of email. So people ended up digressing and debating minor off-topic points, because it's bluntly too hard to come up with a polite, clear explanation, suitable for an email, of why certain people's writing styles are hard to work with (and even if someone did that, it's just stating the problem - proposing a solution is a whole order of magnitude more work). Very few people have the time or the inclination to put a lot of effort into carefully reasoned, well thought through emails. It's too much like writing an essay or a report. But that's what's needed when discussing a complex proposal. And "discussing complex proposals" is essentially the whole point of this list (as I see it). "Hey, wouldn't it be neat if we could do X" is *not* the intended use of the list, and it's precisely those partially (or even not at all) thought out postings that generate the most frustrating, least clear, conversations. Paul From phd at phdru.name Sun Feb 3 08:00:21 2019 From: phd at phdru.name (Oleg Broytman) Date: Sun, 3 Feb 2019 14:00:21 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL In-Reply-To: <20190203112411.GV1834@ando.pearwood.info> References: <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> <20190203112411.GV1834@ando.pearwood.info> Message-ID: <20190203130021.l2psx3mqlnf5jzdp@phdru.name> On Sun, Feb 03, 2019 at 10:24:12PM +1100, Steven D'Aprano wrote: > I'm not sure what multiline editing is being referred to above. I > personally don't know of one in bash. It may be that you have to turn > the feature on -- by default, bash ships with a fair amount of stuff > turned off, and the rest hidden behind cryptic keystroke commands. shopt -s cmdhist From ``man bash``: "If set, bash attempts to save all lines of a multiple-line command in the same history entry. This allows easy re-editing of multi-line commands." > -- > Steve Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From solipsis at pitrou.net Sun Feb 3 09:42:50 2019 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 3 Feb 2019 15:42:50 +0100 Subject: [Python-ideas] Clearer communication References: <20190201183836.GU1834@ando.pearwood.info> <20190202102032.GM1834@ando.pearwood.info> Message-ID: <20190203154250.54eaf4c7@fsol> On Sat, 2 Feb 2019 21:20:40 +1100 Steven D'Aprano wrote: > > Core developer Brett Cannon has taken up editing other people's comments > on github if he doesn't approve of their tone. > > I'm now proactively editing people's comments on issues so > they are less aggressive, e.g. "You need" becomes "it would > be great if", etc. > > https://twitter.com/brettsky/status/1006660998860640256 > > And later: > > If they don't like it then I will simply ban them. > > Take note of how many people responding to Brett think it is a wonderful > idea. The ability to edit other people's posts is considered a feature, > not a bug. Those people are probably a small cultural bubble, though. Twitter and other social networks act like echo chambers, not as promoters of rational debate. I've found Brett's stance on this unacceptable and I think I've already said it. Regards Antoine. From solipsis at pitrou.net Sun Feb 3 09:44:08 2019 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 3 Feb 2019 15:44:08 +0100 Subject: [Python-ideas] What factors led Guido to quit? References: Message-ID: <20190203154408.6d8a1060@fsol> James, please don't post such topics on python-ideas. This is completely off-topic and has strong flamebait potential. You may write on your own blog or Facebook account if you feel so strongly about it. Regards Antoine. On Sat, 2 Feb 2019 11:04:40 -0500 James Lu wrote: > I want y?all to think about this very carefully. What factors led Guido to quit? And I don?t want you to just reply with the first thing that comes off your head. The purpose of this question/discussion is to identify problems with the Python community so we can fix them. > > That is the only real chance of having a successful Python language that doesn?t get left behind by other languages, or of getting Guido to come back. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From jamtlu at gmail.com Sat Feb 2 20:29:27 2019 From: jamtlu at gmail.com (James Lu) Date: Sat, 2 Feb 2019 20:29:27 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202085835.GK1834@ando.pearwood.info> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <20190202085835.GK1834@ando.pearwood.info> Message-ID: There is no need for any of you to argue over this small point. Tolerate each other?s language. Sent from my iPhone > On Feb 2, 2019, at 3:58 AM, Steven D'Aprano wrote: > >> On Sat, Feb 02, 2019 at 05:10:14AM +0000, MRAB wrote: >>> On 2019-02-02 04:32, Steven D'Aprano wrote: >>> [snip] >>> >>> Of course it makes sense. Even numpy supports inhomogeneous data: >>> >> [snip] >> >> "inhomogeneous"? Who came up with that? > > I don't know, but it has been used since at least the early 1920s > > https://english.stackexchange.com/questions/194906/heterogeneous-vs-inhomogeneous > > and the Oxford dictionary describes "inhomogenity" as being used from > the late 19th century. So my guess is, probably people who were more > familiar with Latin and Greek than we are. > > There are many words that are derived from both Latin and Greek. There's > no rule that says that because a word was derived from Greek, we must > use Greek grammatical forms for it. We are speaking English, not Greek, > and in English, we can negate words using the "in" prefix. > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From jamtlu at gmail.com Sat Feb 2 23:56:47 2019 From: jamtlu at gmail.com (James Lu) Date: Sat, 2 Feb 2019 23:56:47 -0500 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: <20190202084124.GJ1834@ando.pearwood.info> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: Sent from my iPhone > On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: > >> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovm?ller wrote: >> >>> - the status quo means "no change", so there is no hassle there; >> >> Not quite true. There is a constant hassle of "do I need to write >> datetime.datetime.now() or datetime.now()?" > > My point was that there is no hassle from *making a change* if you don't > actually make a change. (There may, or may not, be other, unrelated > hassles.) > > Besides, I'm not seeing that this is any worse than any other import. Do > I call spam.Eggs.make() or Eggs.make()? If you don't remember what you > imported, the names don't make much difference. > > I accept that datetime.datetime reads a bit funny and is a bit annoying. > If we had the keys to the time machine and could go back a decade to > version 3.0, or even further back to 1.5 or whenever the datetime module > was first created, it would be nice to change it so that the class was > DateTime. But changing it *now* is not free, it has real, serious costs > which are probably greater than the benefit gained. Why can?t we put ?now? as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now? > >> I solved this at work by changing all imports to follow the "from >> datetime import datetime" pattern and hard banning the other >> statically in CI. But before that people suffered for years. > > Oh how they must have suffered *wink* > > I'm surprised that you don't do this: > > from datetime import datetime as DateTime > > >> I have a colleague who likes to point that the future is longer than >> the past. It's important to keep that perspective. > > Actually, no, on average, the projected lifespan of technologies, > companies and cultural memes is about the same as their current age. It > might last less, or it might last more, but the statistical expectation > is about the same as the current age. So on average, "the future" is > about the same as "the past". > > Python has been around not quite 30 years now, so we can expect that it > will probably last another 30 years. But chances are not good that it > will be around in 300 years. A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline. Bottom line: if someone submits a PR for this, will anyone merge it? > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From gadgetsteve at live.co.uk Sun Feb 3 11:07:22 2019 From: gadgetsteve at live.co.uk (Steve Barnes) Date: Sun, 3 Feb 2019 16:07:22 +0000 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: > -----Original Message----- > From: Python-ideas bounces+gadgetsteve=live.co.uk at python.org> On Behalf Of James Lu > Sent: 03 February 2019 04:57 > To: Steven D'Aprano > Cc: python-ideas at python.org > Subject: Re: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] > > > I accept that datetime.datetime reads a bit funny and is a bit annoying. > > If we had the keys to the time machine and could go back a decade to > > version 3.0, or even further back to 1.5 or whenever the datetime > > module was first created, it would be nice to change it so that the > > class was DateTime. But changing it *now* is not free, it has real, > > serious costs which are probably greater than the benefit gained. > Why can?t we put ?now? as a property of the module itself, reccomend that, and > formally deprecate but never actually remove datetime.datetime.now? > > [Steve Barnes] Better yet why not also rename datetime.datetime to datetime.DateTime and include the line: datetime = DateTime. > A big reason why projects last as long as you say they last is that the maintainers > get un-ambitious, they get used to relaxing in the language they know so well, > they are no longer keen on change. > > This kind of readability issue, datetime.now, is an example of what?s > contributing to Python?s decline. > > Bottom line: if someone submits a PR for this, will anyone merge it? > > > > -- [Steve Barnes] Good Points From ericfahlgren at gmail.com Sun Feb 3 11:15:46 2019 From: ericfahlgren at gmail.com (Eric Fahlgren) Date: Sun, 3 Feb 2019 08:15:46 -0800 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: On Sun, Feb 3, 2019 at 7:57 AM James Lu wrote: > > This kind of readability issue, datetime.now, is an example of what?s > contributing to Python?s decline. > Python's decline??? https://pypl.github.io/PYPL.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at trueblade.com Sun Feb 3 11:34:43 2019 From: eric at trueblade.com (Eric V. Smith) Date: Sun, 3 Feb 2019 11:34:43 -0500 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: <8b08f861-b471-803f-a168-18e4c41758cf@trueblade.com> On 2/2/2019 11:56 PM, James Lu wrote: > > > Sent from my iPhone > >> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: >> Python has been around not quite 30 years now, so we can expect that it >> will probably last another 30 years. But chances are not good that it >> will be around in 300 years. > > A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. > > This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline. > > Bottom line: if someone submits a PR for this, will anyone merge it? I would not, and I don't think any other core dev would. There should be one way to do things (insert quibbles about PEP 20 here). I think it's detrimental to the language to introduce a new way of doing exactly the same thing that has existed for ages (maybe decades). And it would not be possible to remove the existing datetime.datetime.now without breaking tons of code, books, tutorials, Stack Overflow answers, etc. I realize we disagree about this, and it frustrates you. But Python has a long history of not making gratuitous changes such as this. Maybe that's one reason it's so popular? Besides: datetime.datetime.now is a pattern we use: classmethods that act as an alternate class constructor. There are tons of examples of this in the stdlib: pathlib.Path.home, factions.Fraction.from_float, and many, many others. These belong in the class that they return, not as a helper in the module. There are plenty of things that annoy me about Python libraries. Some of them I even wrote. But we're not going to start changing things solely for style or consistency issues. Eric From boxed at killingar.net Sun Feb 3 11:55:38 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Sun, 3 Feb 2019 17:55:38 +0100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: <87BAF8FE-99DF-4323-89C2-81D6F39D5A8E@killingar.net> I know I argued for changing this but really I think this is better handled by linters and IDEs by STRONGLY discouraging "import datetime" so people don't get the annoying "'module' object is not callable" or "module 'datetime' has no attribute 'now'" messages. As I said before, this is what I've implemented at work and to us this annoying paper cut has simply gone away. / Anders > On 3 Feb 2019, at 05:56, James Lu wrote: > > > > Sent from my iPhone > >>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: >>> >>>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovm?ller wrote: >>>> >>>> - the status quo means "no change", so there is no hassle there; >>> >>> Not quite true. There is a constant hassle of "do I need to write >>> datetime.datetime.now() or datetime.now()?" >> >> My point was that there is no hassle from *making a change* if you don't >> actually make a change. (There may, or may not, be other, unrelated >> hassles.) >> >> Besides, I'm not seeing that this is any worse than any other import. Do >> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you >> imported, the names don't make much difference. >> >> I accept that datetime.datetime reads a bit funny and is a bit annoying. >> If we had the keys to the time machine and could go back a decade to >> version 3.0, or even further back to 1.5 or whenever the datetime module >> was first created, it would be nice to change it so that the class was >> DateTime. But changing it *now* is not free, it has real, serious costs >> which are probably greater than the benefit gained. > Why can?t we put ?now? as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now? >> >>> I solved this at work by changing all imports to follow the "from >>> datetime import datetime" pattern and hard banning the other >>> statically in CI. But before that people suffered for years. >> >> Oh how they must have suffered *wink* >> >> I'm surprised that you don't do this: >> >> from datetime import datetime as DateTime >> >> >>> I have a colleague who likes to point that the future is longer than >>> the past. It's important to keep that perspective. >> >> Actually, no, on average, the projected lifespan of technologies, >> companies and cultural memes is about the same as their current age. It >> might last less, or it might last more, but the statistical expectation >> is about the same as the current age. So on average, "the future" is >> about the same as "the past". >> >> Python has been around not quite 30 years now, so we can expect that it >> will probably last another 30 years. But chances are not good that it >> will be around in 300 years. > > A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. > > This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline. > > Bottom line: if someone submits a PR for this, will anyone merge it? >> >> -- >> Steve >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From jamtlu at gmail.com Sun Feb 3 12:33:01 2019 From: jamtlu at gmail.com (James Lu) Date: Sun, 3 Feb 2019 12:33:01 -0500 Subject: [Python-ideas] What factors led Guido to quit? In-Reply-To: <20190203154408.6d8a1060@fsol> References: <20190203154408.6d8a1060@fsol> Message-ID: <348685ED-29CD-48CB-97C2-175B3557C5E7@gmail.com> Are you a moderator or committed? I disagree with you. This, like the communication thread, is about improving the ability of the Python community to work together. If you don?t think others can have a respectful discussion about that, that?s the community?s fault, not mine. Again, the goal of this thread is for constructive discussion. Sent from my iPhone > On Feb 3, 2019, at 9:44 AM, Antoine Pitrou wrote: > > > James, please don't post such topics on python-ideas. This is > completely off-topic and has strong flamebait potential. You may write > on your own blog or Facebook account if you feel so strongly about it. > > Regards > > Antoine. > > > On Sat, 2 Feb 2019 11:04:40 -0500 > James Lu wrote: >> I want y?all to think about this very carefully. What factors led Guido to quit? And I don?t want you to just reply with the first thing that comes off your head. The purpose of this question/discussion is to identify problems with the Python community so we can fix them. >> >> That is the only real chance of having a successful Python language that doesn?t get left behind by other languages, or of getting Guido to come back. >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From jamtlu at gmail.com Sun Feb 3 12:34:02 2019 From: jamtlu at gmail.com (James Lu) Date: Sun, 3 Feb 2019 12:34:02 -0500 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> Message-ID: <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> Python?s decline is in not growing. Sent from my iPhone > On Feb 3, 2019, at 11:20 AM, Ned Batchelder wrote: > > James, you say below, "This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline." > > Do you have any evidence of Python's decline? Lots of metrics (albeit simplistic ones) point to Python growing in popularity: > > https://www.techrepublic.com/article/fastest-growing-programming-language-pythons-popularity-is-still-climbing/ > https://www.netguru.com/blog/why-python-is-growing-so-quickly-future-trends > https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language > Are there indicators we are missing? > > --Ned. > >> On 2/2/19 11:56 PM, James Lu wrote: >> Sent from my iPhone >> >>>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: >>>> >>>>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovm?ller wrote: >>>>> >>>>> - the status quo means "no change", so there is no hassle there; >>>> Not quite true. There is a constant hassle of "do I need to write >>>> datetime.datetime.now() or datetime.now()?" >>> My point was that there is no hassle from *making a change* if you don't >>> actually make a change. (There may, or may not, be other, unrelated >>> hassles.) >>> >>> Besides, I'm not seeing that this is any worse than any other import. Do >>> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you >>> imported, the names don't make much difference. >>> >>> I accept that datetime.datetime reads a bit funny and is a bit annoying. >>> If we had the keys to the time machine and could go back a decade to >>> version 3.0, or even further back to 1.5 or whenever the datetime module >>> was first created, it would be nice to change it so that the class was >>> DateTime. But changing it *now* is not free, it has real, serious costs >>> which are probably greater than the benefit gained. >> Why can?t we put ?now? as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now? >>>> I solved this at work by changing all imports to follow the "from >>>> datetime import datetime" pattern and hard banning the other >>>> statically in CI. But before that people suffered for years. >>> Oh how they must have suffered *wink* >>> >>> I'm surprised that you don't do this: >>> >>> from datetime import datetime as DateTime >>> >>> >>>> I have a colleague who likes to point that the future is longer than >>>> the past. It's important to keep that perspective. >>> Actually, no, on average, the projected lifespan of technologies, >>> companies and cultural memes is about the same as their current age. It >>> might last less, or it might last more, but the statistical expectation >>> is about the same as the current age. So on average, "the future" is >>> about the same as "the past". >>> >>> Python has been around not quite 30 years now, so we can expect that it >>> will probably last another 30 years. But chances are not good that it >>> will be around in 300 years. >> A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. >> >> This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline. >> >> Bottom line: if someone submits a PR for this, will anyone merge it? >>> -- >>> Steve >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamtlu at gmail.com Sun Feb 3 12:35:56 2019 From: jamtlu at gmail.com (James Lu) Date: Sun, 3 Feb 2019 12:35:56 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190203000005.GS1834@ando.pearwood.info> References: <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> <20190203000005.GS1834@ando.pearwood.info> Message-ID: <3C716F93-235C-47A0-BCD4-E29583031E58@gmail.com> Well, the question wasn?t about any specific proposal but improving communication in general. I don?t have a specific straw man. Sent from my iPhone > On Feb 2, 2019, at 7:00 PM, Steven D'Aprano wrote: > >> On Sat, Feb 02, 2019 at 10:59:36AM -0500, James Lu wrote: >> >> I think we need to step away from the egalitarian ideal and have some >> way of knowing that Python committees are python committers. It?s >> really difficult to know how well your proposal is doing without >> having this. > > Speaking of clearer communication (see the subject line), who are you > referring to and which proposal do you mean? > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From jamtlu at gmail.com Sun Feb 3 12:44:10 2019 From: jamtlu at gmail.com (James Lu) Date: Sun, 3 Feb 2019 12:44:10 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: <20190203001747.GT1834@ando.pearwood.info> References: <20190201183836.GU1834@ando.pearwood.info> <57D1197E-DC26-4764-95EB-9128BEB314EF@gmail.com> <20190203001747.GT1834@ando.pearwood.info> Message-ID: >> On Feb 2, 2019, at 7:17 PM, Steven D'Aprano wrote: >> >> On Sat, Feb 02, 2019 at 11:12:02AM -0500, James Lu wrote: >> >> This list IS hard for newcomers. I wish there was one place where I >> could read up on how to not feel like a noob. > > It has become unfashionable to link to this, because it is allegedly too > elitest and unfriendly and not welcoming enough, but I still think it is > extremely valuable: > > http://www.catb.org/esr/faqs/smart-questions.html > > (Its also somewhat unpopular because the maintainer has become > something of a politically Right-wing extremist.) > > If you think of *proposals* as a kind of question: > > "What are the Pros and Cons of this suggestion?" > > rather than > > "We must do this. I have spoken, make it so!" > > then the Smart Questions document is relevant. Do your research first. > What have you tried? Have you tried to knock holes in your own proposal > or are you so excited by the Pros that you are blind to the Cons? What > do other languages do? Do they differ from Python in ways which matter > to your proposal? > > Did you make even a feeble attempt to search the archives, > Stackoverflow, etc, or just post the first ill-formed thought that came > to your mind? > > If your proposal been asked before, unless you are bringing something > new to the discussion, don't waste everyone's time covering old ground. That?s some great stuff, can we document it somewhere? I think it would benefit future proposers. I?ve been subconsciously aware of what you said but haven?t been able to express it. From mertz at gnosis.cx Sun Feb 3 12:45:50 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 12:45:50 -0500 Subject: [Python-ideas] What factors led Guido to quit? In-Reply-To: <348685ED-29CD-48CB-97C2-175B3557C5E7@gmail.com> References: <20190203154408.6d8a1060@fsol> <348685ED-29CD-48CB-97C2-175B3557C5E7@gmail.com> Message-ID: Guido left for a variety of personal reasons, only some of which I know. Soon we will have a wonderful new Steering Council who will act as a collective BDFL (except each for finite terms, and not dictator since it's a council... but benevolent :-)). On Sun, Feb 3, 2019, 12:33 PM James Lu Are you a moderator or committed? > > I disagree with you. This, like the communication thread, is about > improving the ability of the Python community to work together. If you > don?t think others can have a respectful discussion about that, that?s the > community?s fault, not mine. > > Again, the goal of this thread is for constructive discussion. > > Sent from my iPhone > > > On Feb 3, 2019, at 9:44 AM, Antoine Pitrou wrote: > > > > > > James, please don't post such topics on python-ideas. This is > > completely off-topic and has strong flamebait potential. You may write > > on your own blog or Facebook account if you feel so strongly about it. > > > > Regards > > > > Antoine. > > > > > > On Sat, 2 Feb 2019 11:04:40 -0500 > > James Lu wrote: > >> I want y?all to think about this very carefully. What factors led Guido > to quit? And I don?t want you to just reply with the first thing that comes > off your head. The purpose of this question/discussion is to identify > problems with the Python community so we can fix them. > >> > >> That is the only real chance of having a successful Python language > that doesn?t get left behind by other languages, or of getting Guido to > come back. > >> _______________________________________________ > >> Python-ideas mailing list > >> Python-ideas at python.org > >> https://mail.python.org/mailman/listinfo/python-ideas > >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sun Feb 3 13:22:53 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 13:22:53 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: On Sun, Feb 3, 2019 at 3:54 AM Adrien Ricocotam wrote: > I think all the issues you have right now would go of using another > operation. I proposed the @ notation that is clear and different from > everything else, > plus the operator is called "matmul" so it completely makes sense. The the > examples would be : > > >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() > >>> v = Vector(l) > >>> len(v) > 12 > >>> v @ len > > I cannot really see how using the @ operator helps anything here. If this were a language that isn't Python (or conceivably some future version of Python, but that doesn't feel likely or desirable to me), I could imagine @ as an operator to vectorize any arbitrary sequence (or iterator). But given that we've already made the sequence into a Vector, there's no need for extra syntax to say it should act in a vectorized way. Moreover, your syntax is awkward for methods with arguments. How would I spell: v.replace('foo', 'bar') In the @ syntax? I actually made an error on my first pass where simply naming a method was calling it. I thought about keeping it for a moment, but that really only allows zero argument calls. I think the principled thing to do here is add the minimal number of methods to Vector itself, and have everything else pass through as vectorized calls. Most of that minimal number are "magic method": __len__(), __contains__(), __str__(), __repr__(), __iter__(), __reversed__(). I might have forgotten a couple. All of those should not be called directly, normally, but act as magic for operators or built-in functions. I think I should then create regular methods of the same name that perform the vectorized version. So we would have: len(v) # -> 12 v.len() # -> list(v) # -> ["Jan", "Feb", "Mar", "Apr", "May", "Jul" ...] v.list() # -> I can't implement every single constructor that users might conceivably want, of course, but I can do it for the basic types in builtins and common standard library. E.g. I might do: v.deque() # -> But I certainly won't manually add: v.custom_linked_list() # From my_inhouse_module.py Hmm... maybe even I could look at names of maybe-constructors in the current namespace and try them. That starts to feel too magic. Falling back to this feels better: map(custom_linked_list, v) # From my_inhouse_module.py -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Sun Feb 3 13:31:49 2019 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Sun, 3 Feb 2019 12:31:49 -0600 Subject: [Python-ideas] What factors led Guido to quit? In-Reply-To: <348685ED-29CD-48CB-97C2-175B3557C5E7@gmail.com> References: <20190203154408.6d8a1060@fsol> <348685ED-29CD-48CB-97C2-175B3557C5E7@gmail.com> Message-ID: - This is a mailing list for discussing ideas for Python, not theorizing about personal reasons for leaving a community, nor for writing prompts. - I would argue he left largely just due to people's influence outside this direct community, but also as a sort of "sign" that it was time to go. That being said, we don't know for sure, because of course we don't live his life, and speculating will get us nowhere. - I seriously doubt he's going to come back. - Antoine is one of the authors of PEP 8002 (the new governance PEP) and has previously received a community service award for his many contributions. -- Ryan (????) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On Sun, Feb 3, 2019, 11:33 AM James Lu wrote: > Are you a moderator or committed? > > I disagree with you. This, like the communication thread, is about > improving the ability of the Python community to work together. If you > don?t think others can have a respectful discussion about that, that?s the > community?s fault, not mine. > > Again, the goal of this thread is for constructive discussion. > > Sent from my iPhone > > > On Feb 3, 2019, at 9:44 AM, Antoine Pitrou wrote: > > > > > > James, please don't post such topics on python-ideas. This is > > completely off-topic and has strong flamebait potential. You may write > > on your own blog or Facebook account if you feel so strongly about it. > > > > Regards > > > > Antoine. > > > > > > On Sat, 2 Feb 2019 11:04:40 -0500 > > James Lu wrote: > >> I want y?all to think about this very carefully. What factors led Guido > to quit? And I don?t want you to just reply with the first thing that comes > off your head. The purpose of this question/discussion is to identify > problems with the Python community so we can fix them. > >> > >> That is the only real chance of having a successful Python language > that doesn?t get left behind by other languages, or of getting Guido to > come back. > >> _______________________________________________ > >> Python-ideas mailing list > >> Python-ideas at python.org > >> https://mail.python.org/mailman/listinfo/python-ideas > >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Sun Feb 3 13:38:43 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sun, 3 Feb 2019 19:38:43 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: I honestly don?t understand what you don?t like the @ syntax. My idea is using functions that takes on argument : an object of the type of the vector. That?s actually how map works. What I understood from your previous message is that there?s ambiguity when using magic functions on whether it?s applied to each element of the vector or the vector itself. That was the first thing I saw. While reading your examples, I noticed that you were using ? my_vec.function() ?. You just said that we will not code the ? .function ? for any function. That?s the other problem I wanted to address with the @ notation. Functions that could be used are then the same we can use in map. But I do agree it?s not easy to have functions with parameters. That?s why I used functools.partial On Sun 3 Feb 2019 at 19:23, David Mertz wrote: > On Sun, Feb 3, 2019 at 3:54 AM Adrien Ricocotam > wrote: > >> I think all the issues you have right now would go of using another >> operation. I proposed the @ notation that is clear and different from >> everything else, >> > plus the operator is called "matmul" so it completely makes sense. The the >> examples would be : >> > > >> >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >> >>> v = Vector(l) >> >>> len(v) >> 12 >> >>> v @ len >> >> > > I cannot really see how using the @ operator helps anything here. If this > were a language that isn't Python (or conceivably some future version of > Python, but that doesn't feel likely or desirable to me), I could imagine @ > as an operator to vectorize any arbitrary sequence (or iterator). But > given that we've already made the sequence into a Vector, there's no need > for extra syntax to say it should act in a vectorized way. > > Moreover, your syntax is awkward for methods with arguments. How would I > spell: > > v.replace('foo', 'bar') > > > In the @ syntax? I actually made an error on my first pass where simply > naming a method was calling it. I thought about keeping it for a moment, > but that really only allows zero argument calls. > > I think the principled thing to do here is add the minimal number of > methods to Vector itself, and have everything else pass through as > vectorized calls. Most of that minimal number are "magic method": > __len__(), __contains__(), __str__(), __repr__(), __iter__(), > __reversed__(). I might have forgotten a couple. All of those should not > be called directly, normally, but act as magic for operators or built-in > functions. > > I think I should then create regular methods of the same name that perform > the vectorized version. So we would have: > > len(v) # -> 12 > > v.len() # -> > > list(v) # -> ["Jan", "Feb", "Mar", "Apr", "May", "Jul" ...] > v.list() # -> > > > I can't implement every single constructor that users might > conceivably want, of course, but I can do it for the basic types in > builtins and common standard library. E.g. I might do: > > v.deque() # -> ... > > > > But I certainly won't manually add: > > v.custom_linked_list() # From my_inhouse_module.py > > > Hmm... maybe even I could look at names of maybe-constructors in the > current namespace and try them. That starts to feel too magic. Falling > back to this feels better: > > map(custom_linked_list, v) # From my_inhouse_module.py > > > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sun Feb 3 13:58:48 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 13:58:48 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: On Sun, Feb 3, 2019 at 1:38 PM Adrien Ricocotam wrote: > I honestly don?t understand what you don?t like the @ syntax. > Can you show any single example that would work with the @ syntax that would not work in almost exactly the same way without it? I have not seen any yet, and none seem obvious. Adding new syntax for its own sake is definitely to be avoided when possible (even though technically the operator exists, so it wouldn't be actual new syntax). > My idea is using functions that takes on argument : an object of the type > of the vector. That?s actually how map works. > I do not understand this. Spell my simple example using @ notation. I.e. my_vec @ replace {something? here for 'foo' with 'bar'} > What I understood from your previous message is that there?s ambiguity > when using magic functions on whether it?s applied to each element of the > vector or the vector itself. That was the first thing I saw. > I decided there really isn't. I think that any function applied to the vector should operate on the sequence as a whole. E.g. what length does it have? Cast it to a different kind of sequence. Print it out. Serialize it. Etc. The things that are vectorized should always be methods of the vector instead. And ALMOST every method should in fact be a vectorized operation. In most cases, those will be a "pass through" to the methods of the items inside of the vector. We won't write every possible method in the Vector class. My toy so far only works with methods that the items actually have. In the examples, string methods. But actually, I should add one method like this: my_vec.apply(lambda x: x*2) That is, we might want to vectorize custom functions also. Maybe in that example we should name the function 'double' for clarity: ' my_vec.apply(double)'. I do think that just a few methods need to be custom programmed because they correspond to magic methods of the items rather than regular names (or not even directly to magic methods, but more machinery). So: my_vec.list() #-> cast each item to a list my_vec.tuple() #-> cast each item to a tuple my_vec.set() #-> cast each item to a set Maybe that's doing too much though. We could always do that with map() or comprehensions; it's not clear it's a common enough use case. Functions that could be used are then the same we can use in map. But I do > agree it?s not easy to have functions with parameters. That?s why I used > functools.partial > I really did not understand how that was meant to work. But it was a whole lot of lines to accomplish something very small either way. > On Sun 3 Feb 2019 at 19:23, David Mertz wrote: > >> On Sun, Feb 3, 2019 at 3:54 AM Adrien Ricocotam >> wrote: >> >>> I think all the issues you have right now would go of using another >>> operation. I proposed the @ notation that is clear and different from >>> everything else, >>> >> plus the operator is called "matmul" so it completely makes sense. The >>> the examples would be : >>> >> >> >>> >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >>> >>> v = Vector(l) >>> >>> len(v) >>> 12 >>> >>> v @ len >>> >>> >> >> I cannot really see how using the @ operator helps anything here. If >> this were a language that isn't Python (or conceivably some future version >> of Python, but that doesn't feel likely or desirable to me), I could >> imagine @ as an operator to vectorize any arbitrary sequence (or >> iterator). But given that we've already made the sequence into a Vector, >> there's no need for extra syntax to say it should act in a vectorized way. >> >> Moreover, your syntax is awkward for methods with arguments. How would I >> spell: >> >> v.replace('foo', 'bar') >> >> >> In the @ syntax? I actually made an error on my first pass where simply >> naming a method was calling it. I thought about keeping it for a moment, >> but that really only allows zero argument calls. >> >> I think the principled thing to do here is add the minimal number of >> methods to Vector itself, and have everything else pass through as >> vectorized calls. Most of that minimal number are "magic method": >> __len__(), __contains__(), __str__(), __repr__(), __iter__(), >> __reversed__(). I might have forgotten a couple. All of those should not >> be called directly, normally, but act as magic for operators or built-in >> functions. >> >> I think I should then create regular methods of the same name that >> perform the vectorized version. So we would have: >> >> len(v) # -> 12 >> >> v.len() # -> >> >> list(v) # -> ["Jan", "Feb", "Mar", "Apr", "May", "Jul" ...] >> v.list() # -> >> >> >> I can't implement every single constructor that users might >> conceivably want, of course, but I can do it for the basic types in >> builtins and common standard library. E.g. I might do: >> >> v.deque() # -> > "b"]) ... > >> >> >> But I certainly won't manually add: >> >> v.custom_linked_list() # From my_inhouse_module.py >> >> >> Hmm... maybe even I could look at names of maybe-constructors in the >> current namespace and try them. That starts to feel too magic. Falling >> back to this feels better: >> >> map(custom_linked_list, v) # From my_inhouse_module.py >> >> >> >> -- >> Keeping medicines from the bloodstreams of the sick; food >> from the bellies of the hungry; books from the hands of the >> uneducated; technology from the underdeveloped; and putting >> advocates of freedom in prisons. Intellectual property is >> to the 21st century what the slave trade was to the 16th. >> > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sun Feb 3 14:01:56 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 14:01:56 -0500 Subject: [Python-ideas] What factors led Guido to quit? In-Reply-To: References: <20190203154408.6d8a1060@fsol> <348685ED-29CD-48CB-97C2-175B3557C5E7@gmail.com> Message-ID: On Sun, Feb 3, 2019 at 1:32 PM Ryan Gonzalez wrote: > - I seriously doubt he's going to come back. > The election for Steering Council is underway, and Guido is one of the candidates. He may or may not be one of 5 members of the SC, but that's up to the voters among the core committers. But if Guido wins, he will be one of several serving for a finite terms (but obviously with great wisdom and experience to lend to the SC). Let's just respect Guido's decision to modify his role, and give great thanks to his huge contributions to the world over decades. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Sun Feb 3 15:16:41 2019 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 3 Feb 2019 21:16:41 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> > On 3 Feb 2019, at 09:54, Adrien Ricocotam wrote: > > Nice that you implemented it ! > > I think all the issues you have right now would go of using another operation. I proposed the @ notation that is clear and different from everything else, > plus the operator is called "matmul" so it completely makes sense. The @ operator is meant for matrix multiplication (see PEP 465) and is already used for that in NumPy. IMHO just that is a good enough reason for not using @ as an elementwise application operator (ignoring if having an such an operator is a good idea in the first place). Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sun Feb 3 15:34:26 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 15:34:26 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren wrote: > The @ operator is meant for matrix multiplication (see PEP 465) and is > already used for that in NumPy. IMHO just that is a good enough reason for > not using @ as an elementwise application operator (ignoring if having an > such an operator is a good idea in the first place). > Co-opting operators is pretty common in Python. For example, the `.__div__()` operator spelled '/' is most often used for some kind of numeric division. Some variations on that, for example vectorized in NumPy. And different numeric types operate a bit differently. The name of the magic method obvious suggests division. And yet, in the standard library we have pathlib which we can use like this (from the module documentation): >>> p = Path('/etc')>>> q = p / 'init.d' / 'reboot' That use is reasonable and iconic, even if it is nothing like division. The `.__mod__()` operator spelled '%' means something very different in relation to a float or int object versus a string object. I.e. modulo division versus string interpolation. I've even seen documentation of some library that coopts `.__matmul__()` to do something with email addresses. It's not a library I use, just something I once saw the documentation on, so I'm not certain of details. But you can imagine that e.g. : email = user @ domain Could be helpful and reasonable (exact behavior and purpose could vary, but it's "something about email" iconically). In other words, I'm not opposed to using the @ operator in my stringpy.Vector class out of purity about the meaning of operators. I just am not convinced that it actually adds anything that is not easier without it. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ned at nedbatchelder.com Sun Feb 3 15:49:42 2019 From: ned at nedbatchelder.com (Ned Batchelder) Date: Sun, 3 Feb 2019 15:49:42 -0500 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> Message-ID: <37654f1e-cfdc-05e2-4197-3dcb1a69df46@nedbatchelder.com> James, frankly, it sounds to me like you have found things you don't like about Python, and are frustrated that your ideas here have not been celebrated.? That's far from "decline."? The process for changing Python is fundamentally conservative, which can be frustrating.? I understand that.? I myself have experienced that frustration. But claiming that Python is in decline, or that something "is the only real chance of having a successful Python language" is just hysteria that won't win over anyone. Now you say Python isn't growing? Do you mean in features, or usage? Either is obviously false. Perhaps you mean that it isn't growing the way that you want? There are things I would change about Python if I could, but I am not the BDFL, and neither are you.? Python is imperfect, because it is made by people, over more than 25 years, and it's got to balance competing demands. It's clear that you are smart and have energy to dedicate to the future of Python.? I hope you find a productive way to contribute. (Sorry for top-posting...) --Ned. On 2/3/19 12:34 PM, James Lu wrote: > Python?s decline is in not growing. > > Sent from my iPhone > > On Feb 3, 2019, at 11:20 AM, Ned Batchelder > wrote: > >> James, you say below, "This kind of readability issue, datetime.now, >> is an example of what?s contributing to Python?s decline." >> >> Do you have any evidence of Python's decline?? Lots of metrics >> (albeit simplistic ones) point to Python growing in popularity: >> >> * https://www.techrepublic.com/article/fastest-growing-programming-language-pythons-popularity-is-still-climbing/ >> * https://www.netguru.com/blog/why-python-is-growing-so-quickly-future-trends >> * https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language >> >> Are there indicators we are missing? >> >> --Ned. >> >> On 2/2/19 11:56 PM, James Lu wrote: >>> Sent from my iPhone >>> >>>> On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: >>>> >>>>> On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovm?ller wrote: >>>>> >>>>>> - the status quo means "no change", so there is no hassle there; >>>>> Not quite true. There is a constant hassle of "do I need to write >>>>> datetime.datetime.now() or datetime.now()?" >>>> My point was that there is no hassle from *making a change* if you don't >>>> actually make a change. (There may, or may not, be other, unrelated >>>> hassles.) >>>> >>>> Besides, I'm not seeing that this is any worse than any other import. Do >>>> I call spam.Eggs.make() or Eggs.make()? If you don't remember what you >>>> imported, the names don't make much difference. >>>> >>>> I accept that datetime.datetime reads a bit funny and is a bit annoying. >>>> If we had the keys to the time machine and could go back a decade to >>>> version 3.0, or even further back to 1.5 or whenever the datetime module >>>> was first created, it would be nice to change it so that the class was >>>> DateTime. But changing it *now* is not free, it has real, serious costs >>>> which are probably greater than the benefit gained. >>> Why can?t we put ?now? as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now? >>>>> I solved this at work by changing all imports to follow the "from >>>>> datetime import datetime" pattern and hard banning the other >>>>> statically in CI. But before that people suffered for years. >>>> Oh how they must have suffered *wink* >>>> >>>> I'm surprised that you don't do this: >>>> >>>> from datetime import datetime as DateTime >>>> >>>> >>>>> I have a colleague who likes to point that the future is longer than >>>>> the past. It's important to keep that perspective. >>>> Actually, no, on average, the projected lifespan of technologies, >>>> companies and cultural memes is about the same as their current age. It >>>> might last less, or it might last more, but the statistical expectation >>>> is about the same as the current age. So on average, "the future" is >>>> about the same as "the past". >>>> >>>> Python has been around not quite 30 years now, so we can expect that it >>>> will probably last another 30 years. But chances are not good that it >>>> will be around in 300 years. >>> A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. >>> >>> This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline. >>> >>> Bottom line: if someone submits a PR for this, will anyone merge it? >>>> -- >>>> Steve >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct:http://python.org/psf/codeofconduct/ >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct:http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Sun Feb 3 16:27:21 2019 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 3 Feb 2019 22:27:21 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: <2E1ECBDA-71E2-4A22-B971-3E51730BBD88@mac.com> > On 3 Feb 2019, at 21:34, David Mertz wrote: > > On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren > wrote: > The @ operator is meant for matrix multiplication (see PEP 465) and is already used for that in NumPy. IMHO just that is a good enough reason for not using @ as an elementwise application operator (ignoring if having an such an operator is a good idea in the first place). > > Co-opting operators is pretty common in Python. For example, the `.__div__()` operator spelled '/' is most often used for some kind of numeric division. Some variations on that, for example vectorized in NumPy. And different numeric types operate a bit differently. The name of the magic method obvious suggests division. I know, but if an element-wise operator is useful it would also be useful for libraries like NumPy that already support the @ operator for matrix multiplication. Using @ both for matrix multiplication and element-wise application could be made to work, but would be very confusing. Ronald ? Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricocotam at gmail.com Sun Feb 3 16:27:45 2019 From: ricocotam at gmail.com (Adrien Ricocotam) Date: Sun, 3 Feb 2019 22:27:45 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: @David Mertz I think I can't explain well my ideas ^^. I'll try to be really detailed so I'm not sure I'm actually saying what I'm thinking. Let's consider the idea of that Vector class this way : Vectors are list of a defined type (may be immutable ?) and adds sugar syntaxing for vectorized operations. Based on this small and not complete enough definition, we should be able to apply any function to that vector. I identify two ways functions are used with vectors : it's either applied on the vector as an iterable/list, or on the elements of this vector. Thus, we need to be have different notations for those two uses. To keep it coherent with Python, if a functions is applied on the vector as an iterable, the vector is given as a parameter : >>> len(v) # Number of elements in the Vector `v` If we want to apply a function on each element of the list, we should then use another notations. So far, several have been proposed. In the following example showing the different notations, we use the generic way so we can apply it to user-defined functions : >>> # Compute the length of each element of the Vector `v` >>> v.apply(len) >>> v @ len Another example with parameters >>> # Replace all "a" by "b" >>> v.apply(lambda s: s.replace("a", "b")) >>> v @ (lambda s: s.replace("a", "b")) My personal opinion is that the two notations feel good. One is standard, the other is not but is less verbose and it's a good point. Now that I detailed everything in my brain and by mail, I guess we are just saying the same thing ! There's something I didn't mention on purpose, it's the use of : `v.lower()` I think having special cases of how vectors works is not a good idea : it's confusing. If we want the user to be able to use user-defined functions we need a notation. Having something different for some of the functions feels weird to me. And obviously, if the user can't use its own functions, this whole thing is pretty useless. Tell me if I got anything wrong. Nb : I found a way to simplify my previous example using lambda instead of partial. Le dim. 3 f?vr. 2019 ? 21:34, David Mertz a ?crit : > On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren > wrote: > >> The @ operator is meant for matrix multiplication (see PEP 465) and is >> already used for that in NumPy. IMHO just that is a good enough reason for >> not using @ as an elementwise application operator (ignoring if having an >> such an operator is a good idea in the first place). >> > > Co-opting operators is pretty common in Python. For example, the > `.__div__()` operator spelled '/' is most often used for some kind of > numeric division. Some variations on that, for example vectorized in > NumPy. And different numeric types operate a bit differently. The name of > the magic method obvious suggests division. > > And yet, in the standard library we have pathlib which we can use like > this (from the module documentation): > > >>> p = Path('/etc')>>> q = p / 'init.d' / 'reboot' > > That use is reasonable and iconic, even if it is nothing like division. > > The `.__mod__()` operator spelled '%' means something very different in > relation to a float or int object versus a string object. I.e. modulo > division versus string interpolation. > > I've even seen documentation of some library that coopts `.__matmul__()` > to do something with email addresses. It's not a library I use, just > something I once saw the documentation on, so I'm not certain of details. > But you can imagine that e.g. : > > email = user @ domain > > > Could be helpful and reasonable (exact behavior and purpose could vary, > but it's "something about email" iconically). > > In other words, I'm not opposed to using the @ operator in my > stringpy.Vector class out of purity about the meaning of operators. I just > am not convinced that it actually adds anything that is not easier without > it. > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamtlu at gmail.com Sun Feb 3 17:31:01 2019 From: jamtlu at gmail.com (James Lu) Date: Sun, 3 Feb 2019 17:31:01 -0500 Subject: [Python-ideas] Mention more alternative implementations on the PSF website Message-ID: https://www.python.org/download/alternatives/ should possibly mention: - Cython and Nuitka - Mention the possibility of compiling Python to WASM - WASM allows Web and Mobile use of Python at possibly native speed. Though not mature yet, Pyodide is a working implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sun Feb 3 17:38:17 2019 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 4 Feb 2019 09:38:17 +1100 Subject: [Python-ideas] Mention more alternative implementations on the PSF website In-Reply-To: References: Message-ID: On Mon, Feb 4, 2019 at 9:32 AM James Lu wrote: > > https://www.python.org/download/alternatives/ should possibly mention: > > - Cython and Nuitka > - Mention the possibility of compiling Python to WASM > - WASM allows Web and Mobile use of Python at possibly native speed. Though not mature yet, Pyodide is a working implementation. > That page lists only the most notable or popular implementations. If you want a list of lesser-known Python implementations, try the community wiki: https://wiki.python.org/moin/PythonImplementations Cython and Nuitka are both there. I don't know how WASM works or how you would compile Python to it, but if "Pyodide" is the name of that compiler, then it's not currently mentioned. You'd be most welcome to add it; since it's a wiki, you don't need anyone's permission (other than a basic anti-spambot check if you've never edited before). ChrisA From eric at trueblade.com Sun Feb 3 17:41:54 2019 From: eric at trueblade.com (Eric V. Smith) Date: Sun, 3 Feb 2019 17:41:54 -0500 Subject: [Python-ideas] Mention more alternative implementations on the PSF website In-Reply-To: References: Message-ID: > On Feb 3, 2019, at 5:31 PM, James Lu wrote: > > https://www.python.org/download/alternatives/ should possibly mention: > > - Cython and Nuitka > - Mention the possibility of compiling Python to WASM > - WASM allows Web and Mobile use of Python at possibly native speed. Though not mature yet, Pyodide is a working implementation. > I suggest opening an issue at https://github.com/python/pythondotorg/issues Although personally I think it?s too early to mention WASM. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Sun Feb 3 17:48:41 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 04 Feb 2019 11:48:41 +1300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: <5C576FC9.8040102@canterbury.ac.nz> Adrien Ricocotam wrote: > I honestly don?t understand what you don?t like the @ syntax. Another probkem with @ is that it already has an intended meaing, i.e. matrix multiplication. What if you have two vectors of matrices and you want to multiply corresponding ones? -- Greg From mertz at gnosis.cx Sun Feb 3 17:58:26 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 17:58:26 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: > > >>> len(v) # Number of elements in the Vector `v` > Agreed, this should definitely be the behavior. So how do we get a vector of lengths of each element? > >>> # Compute the length of each element of the Vector `v` > >>> v.apply(len) > >>> v @ len > Also possible is: v.len() We couldn't do that for every possible function, but this one is special inasmuch as we expect the items each to have a .__len__() but don't want to spell the dunders. Likewise for just a handful of other methods/functions. The key different though is that *I* would want to a way to use both methods already attached to the objects/items. in a vector and also a generic user-provided function that operates on the items. I guess you disagree about "method pass-through" but it reads more elegantly to me: >>> # Replace all "a" by "b" > >>> v.apply(lambda s: s.replace("a", "b")) > >>> v @ (lambda s: s.replace("a", "b")) > Compare these with: v.replace("a", "b") Since we already know v is a Vector, we kinda expect methods to be vectorized. This feels like the "least surprise" and also the least extra code. Moreover, spelling chained methods with many .appy() calls (even if spelled '@') feels very cumbersome: (A) v.apply(lambda s: s.replace("a", "b")).apply(str.upper).apply(lambda s: s.count("B")) (B) v @ lambda s: s.replace("a", "b") @ str.upper @ lambda s: s.count("B") (C) v.replace("a","b").upper().count("B") Between these, (C) feels a heck of a lot more intuitive and readable to me. Here we put an emphasis on the methods already attached to objects. But this isn't terrible: def double(x): return x*2 v.apply(double).replace("a","b").upper().count("B") In @ notation it would be: v @ double @ lambda s: s.replace("a", "b") @ str.upper @ lambda s: s.count("B") The 'double' is slightly easier, but the method calls are much worse. MOREOVER, the model of "everything is apply/@" falls down terribly once we have duck typing. This is a completely silly example, but it's one that apply/@ simply cannot address because it assumes it is the SAME function/method applied to each object: >>> class CaseInsensitiveStr(str): ... def replace(self, old, new): ... return str.upper(self).replace(old.upper(), new.upper()) ... >>> l = ['Monday', CaseInsensitiveStr('Tuesday'), 'Wednesday'] >>> v = Vector(l) >>> v.replace('day', 'time') -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Sun Feb 3 18:01:56 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 4 Feb 2019 10:01:56 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> Message-ID: <20190203230156.GY1834@ando.pearwood.info> James, Ned, and everyone else, (I'm intentionally leaving the subject line untouched, but since James' message was sent to the list, I'm replying to the list.) In another thread, you (James) asked for ways to not feel like such a n00b, and you attempted (with mixed success) to start a discussion about improving the quality of communication here. So in the spirit of constructive criticism so that you and others can learn from experience and communicate better: (1) Taking the group discussion off-list should be done rarely, and usually only for personal messages that shouldn't be shared publically, or by mutual agreement for off-topic discussions. I can't see Ned's original comment in either my inbox, or at the archives, so it seems that he took the discussion off-list. I don't know why. It doesn't strike me as either personal or off-topic, so taking it off-list seems to be both unnecessary and a little rude to the rest of the group -- why were the rest of us excluded? But since Ned apparently intended to take it off-list, it is only polite to respect that your reply. (2) The long-standing tradition is to put "OFFLIST" at the *start* of the subject line, not the end where it is easy to overlook. To make it even more clear, we should explicitly state that the message is off-list at the top of the message. (Especially if you intend the message to be confidential.) (3) In the thread about improving communication, I mentioned that the easier it is to make comments, the more likely it is for people to make poor-quality comments. In my experience, posting from a phone is one of those tools that encourages poor-quality comments. It is each person's responsibility to either use a better communication tool (better does not necessarily mean more convenient) or to manage their own use of the tool better. I've seen too many people blame their tools for their own repeated mistakes: "I can't help it, it's my phone, it makes it too hard to do the right thing." Who is the master, them or their phone? We're all only human and therefore make mistakes, but we ought to own them when we do, and learn from them, not fob responsibility off to the tools we choose to use. (4) Speaking of poor-quality comments, you said "Python?s decline is in not growing." Do you have evidence that Python is "not growing" or did you just make that up? On Sun, Feb 03, 2019 at 12:34:02PM -0500, James Lu wrote: > Python?s decline is in not growing. > > Sent from my iPhone -- Steven From greg.ewing at canterbury.ac.nz Sun Feb 3 18:08:08 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 04 Feb 2019 12:08:08 +1300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <2E1ECBDA-71E2-4A22-B971-3E51730BBD88@mac.com> References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> <2E1ECBDA-71E2-4A22-B971-3E51730BBD88@mac.com> Message-ID: <5C577458.1060207@canterbury.ac.nz> Ronald Oussoren via Python-ideas wrote: > >> On 3 Feb 2019, at 21:34, David Mertz > > wrote: >> >> Using @ both for matrix multiplication and > element-wise application could be made to work, but would be very > confusing. The way @ is defined in numpy does actually work for both. E.g. v1 @ v2 where v1 and v2 are 3-dimensional arrays is equivalent to multiplying two 1D arrays of 2D matrices elementwise. Is this confusing? Maybe, but it's certainly useful. -- Greg From steve at pearwood.info Sun Feb 3 18:19:13 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 4 Feb 2019 10:19:13 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: <20190203231912.GZ1834@ando.pearwood.info> On Sat, Feb 02, 2019 at 11:56:47PM -0500, James Lu wrote: > > I accept that datetime.datetime reads a bit funny and is a bit annoying. > > If we had the keys to the time machine and could go back a decade to > > version 3.0, or even further back to 1.5 or whenever the datetime module > > was first created, it would be nice to change it so that the class was > > DateTime. But changing it *now* is not free, it has real, serious costs > > which are probably greater than the benefit gained. > Why can?t we put ?now? as a property of the module itself, reccomend > that, and formally deprecate but never actually remove > datetime.datetime.now? The first half of that suggestion has merit. I would definitely appreciate a pair of top-level helper functions that returned the current date and current datetime. They might even be as simple as this: # In the datetime module today = date.today now = datetime.now But there is no reason to deprecate the existing functionality. It isn't broken or harmful. There's no need to remove it. Being able to construct a new date or datetime object using a method of the class is a perfectly natural thing to do. And deprecating a feature that you have no intention of removing just adds noise to the language. [...] > > Actually, no, on average, the projected lifespan of technologies, > > companies and cultural memes is about the same as their current age. It > > might last less, or it might last more, but the statistical expectation > > is about the same as the current age. So on average, "the future" is > > about the same as "the past". > > > > Python has been around not quite 30 years now, so we can expect that it > > will probably last another 30 years. But chances are not good that it > > will be around in 300 years. > > A big reason why projects last as long as you say they last is that > the maintainers get un-ambitious, they get used to relaxing in the > language they know so well, they are no longer keen on change. Possibly the most widely-used language in the world, C, is also far more conservative and slow-changing than Python. (Python is about in the middle as far as speed of change.) We put out new features roughly every 18 months. C brings them out about once a decade. Whether we love or hate C, it is pretty clear that it is not going away any time soon. -- Steven From steve at pearwood.info Sun Feb 3 18:26:41 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 4 Feb 2019 10:26:41 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> Message-ID: <20190203232640.GA1834@ando.pearwood.info> On Sun, Feb 03, 2019 at 04:07:22PM +0000, Steve Barnes wrote: > Better yet why not also rename datetime.datetime to datetime.DateTime > and include the line: datetime = DateTime. That was already discussed in this thread. -- Steven From python at mrabarnett.plus.com Sun Feb 3 18:34:36 2019 From: python at mrabarnett.plus.com (MRAB) Date: Sun, 3 Feb 2019 23:34:36 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: On 2019-02-03 22:58, David Mertz wrote: > >>> len(v)? # Number of elements in the Vector `v` > > > Agreed, this should definitely be the behavior.? So how do we get a > vector of lengths of each element? > > >>> # Compute the length of each element of the Vector `v` > >>> v.apply(len) > >>> v @ len > > > Also possible is: > > ? ? v.len() > > We couldn't do that for every possible function, but this one is special > inasmuch as we expect the items each to have a .__len__() but don't want > to spell the dunders. Likewise for just a handful of other > methods/functions. > > The key different though is that *I* would want to a way to use both > methods already attached to the objects/items. in a vector and also a > generic user-provided function that operates on the items. I guess you > disagree about "method pass-through" but it reads more elegantly to me: > > >>> # Replace all "a" by "b" > >>> v.apply(lambda s: s.replace("a", "b")) > >>> v @ (lambda s: s.replace("a", "b")) > > > Compare these with: > > ? ? v.replace("a", "b") > > Since we already know v is a Vector, we kinda expect methods to be > vectorized.? This feels like the "least surprise" and also the least > extra code.? Moreover, spelling chained methods with many .appy() calls > (even if spelled '@') feels very cumbersome: > Do they need multiple uses of apply and @? > (A) v.apply(lambda s: s.replace("a", "b")).apply(str.upper).apply(lambda > s: s.count("B")) > v.apply(lambda s: s.replace("a", "b").upper().count("B")) > (B) v?@ lambda s: s.replace("a", "b") @ str.upper? @ lambda s: s.count("B") > v @ lambda s: s.replace("a", "b").upper().count("B") > (C) v.replace("a","b").upper().count("B") > > Between these, (C) feels a heck of a lot more intuitive and readable to me. > [snip] From greg.ewing at canterbury.ac.nz Sun Feb 3 18:34:15 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 04 Feb 2019 12:34:15 +1300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: <5C577A77.7010301@canterbury.ac.nz> Adrien Ricocotam wrote: > >>> # Compute the length of each element of the Vector `v` > >>> v.apply(len) > >>> v @ len > > Another example with parameters > >>> # Replace all "a" by "b" > >>> v.apply(lambda s: s.replace("a", "b")) > >>> v @ (lambda s: s.replace("a", "b")) > > My personal opinion is that the two notations feel good. But they only cover the special case of a function that takes elements from just one input vector. What about one that takes coresponding elements from two or more vectors? -- Greg From robertve92 at gmail.com Sun Feb 3 18:39:21 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Mon, 4 Feb 2019 00:39:21 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <5C56012D.1000704@brenbarn.net> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <5C56012D.1000704@brenbarn.net> Message-ID: On Sat, 2 Feb 2019, 21:46 Brendan Barnwell some_list @ str.lower @ tokenize @ remove_stopwords > ? some_list @ to(str.lower) @ to(tokenize) @ to(remove_stopwords) Where from funcoperators import postfix as to -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Sun Feb 3 18:48:37 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 18:48:37 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <5C577A77.7010301@canterbury.ac.nz> References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> <5C577A77.7010301@canterbury.ac.nz> Message-ID: On Sun, Feb 3, 2019, 6:36 PM Greg Ewing > But they only cover the special case of a function that takes > elements from just one input vector. What about one that takes > coresponding elements from two or more vectors? > What syntax would you like? Not necessarily new syntax per se, but what calling convention. I can think of a few useful cases. vec1.replace("PLACEHOLDER", vec2) Maybe that would transform one vector using the corresponding strings from another vector. What should happen if the vector length mismatch? I think this should probably be an exception... unlike what zip() and itertools.zip_longest() do. But maybe not. concat = vec1 + vec2 Again the vector length question is there. But assuming the same length, this seems like a reasonable way to get a new vector concatenating each corresponding element. Other uses? Are they different in general pattern? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Sun Feb 3 18:50:41 2019 From: rosuav at gmail.com (Chris Angelico) Date: Mon, 4 Feb 2019 10:50:41 +1100 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <20190203230156.GY1834@ando.pearwood.info> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> <20190203230156.GY1834@ando.pearwood.info> Message-ID: On Mon, Feb 4, 2019 at 10:02 AM Steven D'Aprano wrote: > (3) In the thread about improving communication, I mentioned that the > easier it is to make comments, the more likely it is for people to make > poor-quality comments. In my experience, posting from a phone is one of > those tools that encourages poor-quality comments. > > It is each person's responsibility to either use a better communication > tool (better does not necessarily mean more convenient) or to manage > their own use of the tool better. I've seen too many people blame their > tools for their own repeated mistakes: "I can't help it, it's my phone, > it makes it too hard to do the right thing." Who is the master, them or > their phone? Let's see. * You don't usually get much, if any, choice of operating system * Even if you can get a terminal app, it doesn't get true access, especially not root * "Jailbreaking" your phone - that is, getting actual access to it - generally voids your warranty You don't own your phone. It owns you. I don't carry a phone. Terrible UI, locked-down device, the ONLY thing it has going for it is that it fits in your hand/pocket. I'd much rather carry a laptop (running Debian GNU/Linux). True, my mobile connection still comes from a device I don't have control of, but it's JUST a network connection, using standard 802.11 to communicate with the laptop. ChrisA From mertz at gnosis.cx Sun Feb 3 18:54:37 2019 From: mertz at gnosis.cx (David Mertz) Date: Sun, 3 Feb 2019 18:54:37 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <5C56012D.1000704@brenbarn.net> Message-ID: How would you spell these with funcoperators? v.replace("a","b").upper().count("B") vec1.replace("PLACEHOLDER", vec2) concat = vec1 + vec2 On Sun, Feb 3, 2019, 6:40 PM Robert Vanden Eynde > > On Sat, 2 Feb 2019, 21:46 Brendan Barnwell > Yeah, it's called pip install funcoperators : > >> some_list @ str.lower @ tokenize @ remove_stopwords >> > > ? some_list @ to(str.lower) @ to(tokenize) @ to(remove_stopwords) > > Where from funcoperators import postfix as to > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ned at nedbatchelder.com Sun Feb 3 19:34:36 2019 From: ned at nedbatchelder.com (Ned Batchelder) Date: Sun, 3 Feb 2019 19:34:36 -0500 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <20190203230156.GY1834@ando.pearwood.info> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> <20190203230156.GY1834@ando.pearwood.info> Message-ID: <7f5cf988-128b-7e81-3e7e-df574e11045a@nedbatchelder.com> On 2/3/19 6:01 PM, Steven D'Aprano wrote: > (1) Taking the group discussion off-list should be done rarely, and > usually only for personal messages that shouldn't be shared > publically, or by mutual agreement for off-topic discussions. > > I can't see Ned's original comment in either my inbox, or at the > archives, so it seems that he took the discussion off-list. I don't know > why. It doesn't strike me as either personal or off-topic, so taking it > off-list seems to be both unnecessary and a little rude to the rest of > the group -- why were the rest of us excluded? > > But since Ned apparently intended to take it off-list, it is only polite > to respect that your reply. > > > (2) The long-standing tradition is to put "OFFLIST" at the *start* of > the subject line, not the end where it is easy to overlook. > > To make it even more clear, we should explicitly state that the > message is off-list at the top of the message. > > (Especially if you intend the message to be confidential.) I replied to James privately because I felt that the question of "Python's decline," and James' reasons for believing it to be so, were not on-topic for a list about suggestions for improving Python.? It also seemed to me that it could easily devolve into an unproductive discussion for such a large group.? But, it was probably also of interest to the group, many of whom were probably wondering the same things I was, so I can see how it could have stayed in the list (where it now is.) It also seemed to me to be a topic which could easily result in James feeling at a disadvantage, being on the other side of a subjective debate from the bulk of the group. I had hoped to discuss it with him in a setting that was less likely to get heated. I didn't mean to be rude to anyone. --Ned. From tjreedy at udel.edu Sun Feb 3 20:06:56 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 3 Feb 2019 20:06:56 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <57D1197E-DC26-4764-95EB-9128BEB314EF@gmail.com> <20190203001747.GT1834@ando.pearwood.info> Message-ID: On 2/3/2019 12:44 PM, James Lu wrote: > On Feb 2, 2019, at 7:17 PM, Steven D'Aprano wrote: >> It has become unfashionable to link to this, because it is allegedly too >> elitest and unfriendly and not welcoming enough, but I still think it is >> extremely valuable: >> >> http://www.catb.org/esr/faqs/smart-questions.html >> >> (Its also somewhat unpopular because the maintainer has become >> something of a politically Right-wing extremist.) >> >> If you think of *proposals* as a kind of question: >> >> "What are the Pros and Cons of this suggestion?" >> >> rather than >> >> "We must do this. I have spoken, make it so!" >> >> then the Smart Questions document is relevant. Do your research first. >> What have you tried? Have you tried to knock holes in your own proposal >> or are you so excited by the Pros that you are blind to the Cons? What >> do other languages do? Do they differ from Python in ways which matter >> to your proposal? >> >> Did you make even a feeble attempt to search the archives, >> Stackoverflow, etc, or just post the first ill-formed thought that came >> to your mind? >> >> If your proposal been asked before, unless you are bringing something >> new to the discussion, don't waste everyone's time covering old ground. > That?s some great stuff, can we document it somewhere? I think it would benefit future proposers. *This list* is documented at https://mail.python.org/mailman/listinfo/python-ideas. I think a short paragraph starting "Before you post a proposal, ...", based on what Steven posted above, would be a good idea, and as useful as 'respect the COC'. Please give it a go and post a proposed addition here. Once polished, a proposal for that page would go to the list owners if they don't notice it. python-ideas-owner at python.org -- Terry Jan Reedy From tjreedy at udel.edu Sun Feb 3 20:29:19 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 3 Feb 2019 20:29:19 -0500 Subject: [Python-ideas] What factors led Guido to quit? In-Reply-To: References: Message-ID: On 2/2/2019 11:04 AM, James Lu wrote: > What factors led Guido to quit? Guido resigned as 'Enhancement Czar'. He wrote what he want to say publicly as to why in his message to the committers list. Speculating beyond that strikes me as rude. He did not resign as President of the PSF nor as active core developer. He recently committed a large chunk of code. Antoine is correct that 'Python community enhancement' is off-topic *here*. This list is for "discussion of speculative language ideas for Python for possible inclusion into the language". https://mail.python.org/mailman/listinfo/python-ideas -- Terry Jan Reedy From hasan.diwan at gmail.com Sun Feb 3 20:35:15 2019 From: hasan.diwan at gmail.com (Hasan Diwan) Date: Sun, 3 Feb 2019 17:35:15 -0800 Subject: [Python-ideas] What factors led Guido to quit? In-Reply-To: References: Message-ID: James, Beginning an email with "I want y?all to think about this very carefully" isn't going to get you the answer you want. It would have been better, if you're curious as to why Guido "quit", the best way would be to go through the archives of python-dev, as he did enumerate the reasons in a note sent to that list. That's all most of us are going to be forthcoming with out of respect for his privacy. -- H On Sun, 3 Feb 2019 at 17:30, Terry Reedy wrote: > On 2/2/2019 11:04 AM, James Lu wrote: > > What factors led Guido to quit? > > Guido resigned as 'Enhancement Czar'. He wrote what he want to say > publicly as to why in his message to the committers list. Speculating > beyond that strikes me as rude. > He did not resign as President of the PSF nor as active core developer. > He recently committed a large chunk of code. > > Antoine is correct that 'Python community enhancement' is off-topic > *here*. This list is for "discussion of speculative language ideas for > Python for possible inclusion into the language". > https://mail.python.org/mailman/listinfo/python-ideas > > -- > Terry Jan Reedy > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1 If you wish to request my time, please do so using *bit.ly/hd1AppointmentRequest *. Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest *. Sent from my mobile device Envoye de mon portable -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Sun Feb 3 20:38:10 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 3 Feb 2019 20:38:10 -0500 Subject: [Python-ideas] Clearer communication In-Reply-To: References: <20190201183836.GU1834@ando.pearwood.info> <699dce5b-64ce-67a5-d88d-d9de5c7cbafc@potatochowder.com> Message-ID: On 2/2/2019 10:59 AM, James Lu wrote: > I think we need to ... have some way of knowing that Python committees are python committers. It?s really difficult to know how well your proposal is doing without having this. That has occurred to me also. If two or three core developers respond negatively and none favorably, the proposal is likely dead, at least in its initial form. On bug.python.org issues, we are marked with the blue and yellow Python snakes. The sidebar has a link Committer List. If I click it when logged in, I see a list of 173 people (most inactive). This will not include Committers not registered on the tracker. Not logged in, I see the first batch of all 20000+ registered users, which seems like a bug. I don't know what you would see. There are perhaps 10 core developers who currently read the list with any regularity. On today's messages, besides myself, I recognize Stephen D'Aprano, Ronald Oussoren, Paul Moore, Antoine Pitrou, and Eric V. Smith. -- Terry Jan Reedy From pythonchb at gmail.com Sun Feb 3 22:08:22 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sun, 3 Feb 2019 21:08:22 -0600 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <2E1ECBDA-71E2-4A22-B971-3E51730BBD88@mac.com> References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> <2E1ECBDA-71E2-4A22-B971-3E51730BBD88@mac.com> Message-ID: > I know, but if an element-wise operator is useful it would also be useful > for libraries like NumPy that already support the @ operator for matrix > multiplication. > A bit of history: A fair amount of inspiration (or at least experience) for numpy came from MATLAB. MATLAB has essentially two complete sets of math operators: the regular version, and the dot version. A * B Means matrix multiplication, and A .* B Means elementwise multiplication. And there is a full set of matrix and elementwise operators. Back in the day, Numeric (numpy?s predecessor?) used the math operators for elementwise operations, and doing matrix math was unwieldy. There was a lit of discussion and a number of proosals for s full set of additional operators in python that could be used for matrix operations ( side note: there was (is) a numpy.matrix class that defines __mul__ as matrix multiplication). Someone at some point realized that we didn?t need a full set, because multiplication was really the only compelling use case. So the @ operator was added. End history. Numpy, or course, is but one third party package, but it is an important one ? major inconsistency with it is a bad idea. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamtlu at gmail.com Sun Feb 3 22:16:47 2019 From: jamtlu at gmail.com (James Lu) Date: Sun, 3 Feb 2019 22:16:47 -0500 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <7f5cf988-128b-7e81-3e7e-df574e11045a@nedbatchelder.com> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> <20190203230156.GY1834@ando.pearwood.info> <7f5cf988-128b-7e81-3e7e-df574e11045a@nedbatchelder.com> Message-ID: <4768689A-1C61-4C62-B443-FB75B51CD3DF@gmail.com> I agree with everything all of you have said in reply to me. Sent from my iPhone > On Feb 3, 2019, at 7:34 PM, Ned Batchelder wrote: > >> On 2/3/19 6:01 PM, Steven D'Aprano wrote: >> (1) Taking the group discussion off-list should be done rarely, and >> usually only for personal messages that shouldn't be shared >> publically, or by mutual agreement for off-topic discussions. >> >> I can't see Ned's original comment in either my inbox, or at the >> archives, so it seems that he took the discussion off-list. I don't know >> why. It doesn't strike me as either personal or off-topic, so taking it >> off-list seems to be both unnecessary and a little rude to the rest of >> the group -- why were the rest of us excluded? >> >> But since Ned apparently intended to take it off-list, it is only polite >> to respect that your reply. >> >> >> (2) The long-standing tradition is to put "OFFLIST" at the *start* of >> the subject line, not the end where it is easy to overlook. >> >> To make it even more clear, we should explicitly state that the >> message is off-list at the top of the message. >> >> (Especially if you intend the message to be confidential.) > > I replied to James privately because I felt that the question of "Python's decline," and James' reasons for believing it to be so, were not on-topic for a list about suggestions for improving Python. It also seemed to me that it could easily devolve into an unproductive discussion for such a large group. But, it was probably also of interest to the group, many of whom were probably wondering the same things I was, so I can see how it could have stayed in the list (where it now is.) > > It also seemed to me to be a topic which could easily result in James feeling at a disadvantage, being on the other side of a subjective debate from the bulk of the group. I had hoped to discuss it with him in a setting that was less likely to get heated. > > I didn't mean to be rude to anyone. > > --Ned. > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From pythonchb at gmail.com Mon Feb 4 00:34:37 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sun, 3 Feb 2019 21:34:37 -0800 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> Message-ID: This is getting pretty off toipic, but I want to point out hat as a rule, Python has been critisised more for having too MUCH cnage than too little over the last few years: The py2 -> 3 transition Adding "yet another" formatting option (f-strings) Adding := The async stuff Granted, these are bigger deals than changing the spelling of stdlib class, but the point is that people want consistency as much (or more) as new features. And changing something like the spelling of datetime buys us exactly nothing in terms of expressiveness, etc. Finally, what the heck is wrong with datetime.now ? making it a classmethod keeps everything in one namespace, so you can reasonably do: from datetime import datetime, timedelta and be done with it. -CHB On Sun, Feb 3, 2019 at 9:34 AM James Lu wrote: > Python?s decline is in not growing. > > Sent from my iPhone > > On Feb 3, 2019, at 11:20 AM, Ned Batchelder wrote: > > James, you say below, "This kind of readability issue, datetime.now, is an > example of what?s contributing to Python?s decline." > > Do you have any evidence of Python's decline? Lots of metrics (albeit > simplistic ones) point to Python growing in popularity: > > - > https://www.techrepublic.com/article/fastest-growing-programming-language-pythons-popularity-is-still-climbing/ > - > https://www.netguru.com/blog/why-python-is-growing-so-quickly-future-trends > - > https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language > > Are there indicators we are missing? > > --Ned. > On 2/2/19 11:56 PM, James Lu wrote: > > Sent from my iPhone > > > On Feb 2, 2019, at 3:41 AM, Steven D'Aprano wrote: > > > On Sat, Feb 02, 2019 at 12:06:47AM +0100, Anders Hovm?ller wrote: > > > - the status quo means "no change", so there is no hassle there; > > Not quite true. There is a constant hassle of "do I need to write > datetime.datetime.now() or datetime.now()?" > > My point was that there is no hassle from *making a change* if you don't > actually make a change. (There may, or may not, be other, unrelated > hassles.) > > Besides, I'm not seeing that this is any worse than any other import. Do > I call spam.Eggs.make() or Eggs.make()? If you don't remember what you > imported, the names don't make much difference. > > I accept that datetime.datetime reads a bit funny and is a bit annoying. > If we had the keys to the time machine and could go back a decade to > version 3.0, or even further back to 1.5 or whenever the datetime module > was first created, it would be nice to change it so that the class was > DateTime. But changing it *now* is not free, it has real, serious costs > which are probably greater than the benefit gained. > > Why can?t we put ?now? as a property of the module itself, reccomend that, and formally deprecate but never actually remove datetime.datetime.now? > > I solved this at work by changing all imports to follow the "from > datetime import datetime" pattern and hard banning the other > statically in CI. But before that people suffered for years. > > Oh how they must have suffered *wink* > > I'm surprised that you don't do this: > > from datetime import datetime as DateTime > > > > I have a colleague who likes to point that the future is longer than > the past. It's important to keep that perspective. > > Actually, no, on average, the projected lifespan of technologies, > companies and cultural memes is about the same as their current age. It > might last less, or it might last more, but the statistical expectation > is about the same as the current age. So on average, "the future" is > about the same as "the past". > > Python has been around not quite 30 years now, so we can expect that it > will probably last another 30 years. But chances are not good that it > will be around in 300 years. > > A big reason why projects last as long as you say they last is that the maintainers get un-ambitious, they get used to relaxing in the language they know so well, they are no longer keen on change. > > This kind of readability issue, datetime.now, is an example of what?s contributing to Python?s decline. > > Bottom line: if someone submits a PR for this, will anyone merge it? > > -- > Steve > _______________________________________________ > Python-ideas mailing listPython-ideas at python.orghttps://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing listPython-ideas at python.orghttps://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Mon Feb 4 00:46:44 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sun, 3 Feb 2019 21:46:44 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: I've lost track if who is advocating what, but: > >>> # Replace all "a" by "b" > >>> v.apply(lambda s: s.replace("a", "b")) >> > I do not get the point of this at all -- we already have map" map(v, lambda s s.replace()"a,", "b") these seem equally expressive an easy to me, and map doesn't require a custom class of anything new at all. > v.replace("a", "b") > This is adding something - maybe just compactness, but I also think readability. I've also lost track of whether anyone is proposing a "vector of strings' as opposed to a vector of arbitrary objects. I think a vector strings could be useful and then it would be easier to decide which string methods should be applied to items vs the vector as a whole. If you want to do any generic items, it becomes a lot harder. I think numpy has had the success it has because it assumes all dytpes are numerical and thus support (mostly) the same operations. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Mon Feb 4 01:57:59 2019 From: stefan_ml at behnel.de (Stefan Behnel) Date: Mon, 4 Feb 2019 07:57:59 +0100 Subject: [Python-ideas] Mention more alternative implementations on the PSF website In-Reply-To: References: Message-ID: Eric V. Smith schrieb am 03.02.19 um 23:41: >> On Feb 3, 2019, at 5:31 PM, James Lu wrote: >> https://www.python.org/download/alternatives/ should possibly mention: >> - Mention the possibility of compiling Python to WASM >> - WASM allows Web and Mobile use of Python at possibly native speed. Though not mature yet, Pyodide is a working implementation. > > I suggest opening an issue at https://github.com/python/pythondotorg/issues > > Although personally I think it?s too early to mention WASM. I agree about the maturity problem, but you could argue that Pyodide is essentially a "repackaging of CPython for WASM", which would belong into the second list on the page, once it reaches a level of compatibility and reliability that makes it relevant for users. Stefan From p.f.moore at gmail.com Mon Feb 4 06:16:49 2019 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 4 Feb 2019 11:16:49 +0000 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> Message-ID: On Mon, 4 Feb 2019 at 05:36, Christopher Barker wrote: > > This is getting pretty off toipic, but I want to point out hat as a rule, Python has been critisised more for having too MUCH cnage than too little over the last few years: [...] > Finally, what the heck is wrong with datetime.now ? Surely what's wrong is the fact that it adds another item to the list of changes that people will complain is "too much"? The conservatism in Python's development is not a result of the core devs being change averse, or because of a policy of blocking change. Rather it's because *the user community* reacts so strongly when we change things, so that we feel that stability is what our users want, and try to achieve that while still balancing the need for the language to grow and develop. In a list like this, which represents only a tiny fraction of Python's user community, it's easy to misjudge the appetite Python's users have for change, because this is a self-selecting group of people who are interested in change. That's why the pushback on *any* proposal made here is to ask what benefits it gives, and why in the absence of good arguments for a change, "the status quo wins". Paul PS Personally, I'd love to add a lot of the ideas discussed in this list (although I'm "meh" about datetime.now, it's at best a minor annoyance). But with my "python developer" hat on I have to look beyond that and try to help proposers develop a good case for their suggestions (if indeed they do have sufficient merit). Just saying "yay, that sounds cool" doesn't do that, even if it's my personal instinct. From mertz at gnosis.cx Mon Feb 4 07:10:59 2019 From: mertz at gnosis.cx (David Mertz) Date: Mon, 4 Feb 2019 07:10:59 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: On Mon, Feb 4, 2019, 12:47 AM Christopher Barker > I've lost track if who is advocating what, but: > Well, I made a toy implementation of a Vector class. I'm not sure what that means I advocate other than the existence of a module on GitHub. FWIW, I called the repo 'stringpy' as a start, so that expressed some interest in it being about vectors of strings. But so-far, I haven't found anything that actually needs to be string-like. In general, methods get passed through to their underlying objects and deliberately duck typed, like: v.replace("a", "b") >> > As an extra, we could enforce homogeneity, or even string-nesss specifically. I don't really know what homogeneity means though, once we consider ABCs, subclasses, and duck types that don't use inheritance on r ABC registration. At least so far, I haven't coded anything that would get a performance gain from enforcing the string-nesss of items (but all pure Python so far, no Cython or C) This is adding something - maybe just compactness, but I also think > readability. > I think with changed methods the win gets greater: v.replace("a", "b").upper().apply(myfun) If you want to do any generic items, it becomes a lot harder. > So far, generic has been a lot easier to code than hand-rolled methods. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirillbalunov at gmail.com Mon Feb 4 07:14:02 2019 From: kirillbalunov at gmail.com (Kirill Balunov) Date: Mon, 4 Feb 2019 15:14:02 +0300 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: ??, 3 ????. 2019 ?. ? 21:23, David Mertz : > > I think the principled thing to do here is add the minimal number of > methods to Vector itself, and have everything else pass through as > vectorized calls. Most of that minimal number are "magic method": > __len__(), __contains__(), __str__(), __repr__(), __iter__(), > __reversed__(). I might have forgotten a couple. All of those should not > be called directly, normally, but act as magic for operators or built-in > functions. > > I think I should then create regular methods of the same name that perform > the vectorized version. So we would have: > > len(v) # -> 12 > > v.len() # -> > > list(v) # -> ["Jan", "Feb", "Mar", "Apr", "May", "Jul" ...] > v.list() # -> > > > Hi David! Thank you for taking the time to implement this idea. Sorry, I'm on a trip now and can't try it. From what I've read in this thread, I think I mostly agree with your perception how the vector should work: that `len(v) # -> 12` and that `.some_method()` call must apply to elements (although pedants may argue that in this case there is not much difference). The only moment that I don?t like is `v.len(), v.list() and ...`, for the same reasons - in general this will not work. I also don't like the option with `.apply` - what if `.apply` method is already defined for elements in a vector? > I can't implement every single constructor that users might > conceivably want, of course, but I can do it for the basic types in > builtins and common standard library. E.g. I might do: > > v.deque() # -> ... > > > > But I certainly won't manually add: > > v.custom_linked_list() # From my_inhouse_module.py > > > Hmm... maybe even I could look at names of maybe-constructors in the > current namespace and try them. That starts to feel too magic. Falling > back to this feels better: > > map(custom_linked_list, v) # From my_inhouse_module.py > > > Actually my thoughts on this. At first I thought that for these purposes it is possible to use __call__: len(v) # -> 12 v(len) # -> But it somehow this idea did not fit in my head. Then I found the next way and I think I even like it - to reuse the `__getitem__`, when its argument is a function it means that you apply this function to every element in the vector. len(v) # -> 12 v[len] # -> In this case you can apply any function, even custom_linked_list from my_inhouse_module.py. From this stream I did not understand what desired behavior for unary operations like `vector + 1` and the others. Also what is the desired behaviour for `vector[1:5]`? Considering the above, I would like to take this operation on the contrary: >>> v >>> v[1:] >>> v[i[1:]] # some helper class `i` With kind regards, -gdg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Mon Feb 4 11:12:08 2019 From: mertz at gnosis.cx (David Mertz) Date: Mon, 4 Feb 2019 11:12:08 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131060858.GN1834@ando.pearwood.info> <20190131232307.GR1834@ando.pearwood.info> <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov wrote: > len(v) # -> 12 > > v[len] # -> > > > In this case you can apply any function, even custom_linked_list from > my_inhouse_module.py. > I think I really like this idea. Maybe as an extra spelling but still allow .apply() to do the same thing. It feels reasonably intuitive to me. Not *identical to* indexing in NumPy and Pandas, but sort of in the same spirit as predicative or selection based indices. What do other people on this thread think? Would you learn that easily? Could you teach it? > >>> v[1:] > 'Nov', 'Dec']> > >>> v[i[1:]] # some helper class `i` > 'ov', 'ec']> > > This feels more forced, unfortunately. Something short would be good, but not sure I like this. This is really just a short spelling of pandas.IndexSlice or numpy.s_ It came up in another thread some months ago, but there is another proposal to allow the obvious spelling `slice[start:stop:sep]` as a way of creating slices. Actually, I guess that's all halfway for the above. We'd need to do this still: v[itemgetter(IndexSlicer[1:])] That's way too noisy. I guess I just don't find the lowercase `i` to be iconic enough. I think with a better SHORT name, I'd like: v[Item[1:]] Maybe that's not the name? -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anvinoth7 at gmail.com Mon Feb 4 19:10:30 2019 From: anvinoth7 at gmail.com (vinoth A N) Date: Mon, 4 Feb 2019 16:10:30 -0800 (PST) Subject: [Python-ideas] need python automation code convert MDB files into csv files. Message-ID: <643e5924-87cb-492c-b8a5-1a1f69cfd87c@googlegroups.com> Hello Friends, I am in process of writing python automation code through which I can read the MDB file which contains several tables which need to convert them in multiple CSV file or xlsx file. ## package required import pandas as pd import numpy as np import os import glob from functools import reduce # to know how many csv file and name csv file in current floder os.chdir('C:\\Users\\anvinoth\\Desktop\\BODOPD\\DXA_C2') # code to change working directory extension = 'mdb' result = [i for i in glob.glob('*.{}'.format(extension))] print(result) ['FB4-DXA-C2-BSL.mdb'] import pandas_access as mdb # Listing the tables. for tbl in mdb.list_tables('FB4-DXA-C2-BSL.mdb'): print(tbl) # Read a small table. df =mdb.read_table('FB4-DXA-C2-BSL.mdb', "Patient") i am getting this error WinError 2] The system cannot find the file specified I am searching in google but I did not find a relevant answer could anyone in the group help me out with correct code to convert the MDB file into CSV file? thanks vinoth -------------- next part -------------- An HTML attachment was scrubbed... URL: From ijkl at netc.fr Tue Feb 5 04:12:24 2019 From: ijkl at netc.fr (Jimmy Girardet) Date: Tue, 5 Feb 2019 10:12:24 +0100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: <03baa6e9-748b-8e1a-dcbc-479b533da770@netc.fr> Hi, I'm not sure to understand the real purpose of Vector. Is that a new collection ? Is that a list with a builtin map() function ? Is it a? wrapper to other types ? Should it be iterable ? The clear need explained before is using fluent interface on a collection : MyVector.strip().replace("A","E") Why do we need Vector to behave like list. We just want to work on our strings but with a cleaner/shorter/nicer syntax. My idea (not totally clear in my mind) is that Vector should behave quite like the type it wraps so having only one type. I don't want a collection of strings, I want a MegaString (...) which I can use exactly like alone string. An iteration on Vector would iter like itertools.chain does. At the end, I would only need one more method which would return an iterable of the items like MyVector.explode() For me Vector should be something like that : class Vector: ??? def __init__(self, a_list): ??????? self.data = a_list ??????? self._type = type(self.data[0]) ??????? for data in self.data: ??????????? if type(data) != self._type: ??????????????? raise TypeError ??? def __getattr__(self, name): ??????? fn =? getattr(self._type, name) ??????? def wrapped(*args, **kwargs): ??????????? self.data = [fn(i, *args, **kwargs) for i in self.data] ??????????? return self ??????? return wrapped ??? def explode(self): ????????? return iter(self.data) I'm not saying it should only handle strings but it seems to be the major use case. Jimmy Le 04/02/2019 ? 17:12, David Mertz a ?crit?: > On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov > wrote: > > len(v)? ?# -> 12 > > v[len]? ?# ->? > > > In this case you can apply any function, > even?custom_linked_list?frommy_inhouse_module.py.? > > > I think I really like this idea.? Maybe as an extra spelling but still > allow .apply() to do the same thing. It feels reasonably intuitive to > me. Not *identical to* indexing in NumPy and Pandas, but sort of in > the same spirit as predicative or selection based indices. > > What do other people on this thread think? Would you learn that > easily? Could you teach it? > ? > > >>> v[1:]?? > 'Sep', 'Oct', 'Nov', 'Dec']>?? > >>> v[i[1:]] # some helper class `i` > 'ep', 'ct', 'ov', 'ec']>?? > > > This feels more forced, unfortunately.? Something short would be good, > but not sure I like this.? This is really just a short spelling of > pandas.IndexSlice or?numpy.s_? It came up in another thread some > months ago, but there is another proposal to allow the obvious > spelling `slice[start:stop:sep]` as a way of creating slices. > > Actually, I guess that's all halfway for the above.? We'd need to do > this still: > > v[itemgetter(IndexSlicer[1:])] > > ? > That's way too noisy.? I guess I just don't find the lowercase `i` to > be iconic enough.? I think with a better SHORT name, I'd like: > > v[Item[1:]] > > > ?Maybe that's not the name? > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons.? Intellectual property is > to the 21st century what the slave trade was to the 16th. > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ Le 04/02/2019 ? 17:12, David Mertz a ?crit?: > On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov > wrote: > > len(v)? ?# -> 12 > > v[len]? ?# ->? > > > In this case you can apply any function, > even?custom_linked_list?frommy_inhouse_module.py.? > > > I think I really like this idea.? Maybe as an extra spelling but still > allow .apply() to do the same thing. It feels reasonably intuitive to > me. Not *identical to* indexing in NumPy and Pandas, but sort of in > the same spirit as predicative or selection based indices. > > What do other people on this thread think? Would you learn that > easily? Could you teach it? > ? > > >>> v[1:]?? > 'Sep', 'Oct', 'Nov', 'Dec']>?? > >>> v[i[1:]] # some helper class `i` > 'ep', 'ct', 'ov', 'ec']>?? > > > This feels more forced, unfortunately.? Something short would be good, > but not sure I like this.? This is really just a short spelling of > pandas.IndexSlice or?numpy.s_? It came up in another thread some > months ago, but there is another proposal to allow the obvious > spelling `slice[start:stop:sep]` as a way of creating slices. > > Actually, I guess that's all halfway for the above.? We'd need to do > this still: > > v[itemgetter(IndexSlicer[1:])] > > ? > That's way too noisy.? I guess I just don't find the lowercase `i` to > be iconic enough.? I think with a better SHORT name, I'd like: > > v[Item[1:]] > > > ?Maybe that's not the name? > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons.? Intellectual property is > to the 21st century what the slave trade was to the 16th. > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhodri at kynesim.co.uk Tue Feb 5 06:42:40 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Tue, 5 Feb 2019 11:42:40 +0000 Subject: [Python-ideas] need python automation code convert MDB files into csv files. In-Reply-To: <643e5924-87cb-492c-b8a5-1a1f69cfd87c@googlegroups.com> References: <643e5924-87cb-492c-b8a5-1a1f69cfd87c@googlegroups.com> Message-ID: <51b9000f-e24a-e037-80cd-1cff559da9df@kynesim.co.uk> On 05/02/2019 00:10, vinoth A N wrote: > Hello Friends, Hello there! This is actually a mailing list/newsgroup for discussing ideas for extending and developing the Python language, not for dealing with people's programming problems. I've made some comments here, but in the future could you use python-list at python.org (the mailing list) or comp.lang.python (the newsgroup), please. > I am in process of writing python automation code through which I can read > the MDB file which contains several tables which need to convert them in > multiple CSV file or xlsx file. > > ## package required > import pandas as pd > import numpy as np > import os > import glob > from functools import reduce > > > # to know how many csv file and name csv file in current floder > os.chdir('C:\\Users\\anvinoth\\Desktop\\BODOPD\\DXA_C2') # code to change > working directory > extension = 'mdb' > result = [i for i in glob.glob('*.{}'.format(extension))] Not a bug, but you are making unnecessary work for yourself here. 'extension' is only ever the string "mdb", so why go to all the trouble of formatting it into a string when you could just write: result = [i for i in glob.glob('*.mdb')] > print(result) > > ['FB4-DXA-C2-BSL.mdb'] > > > > import pandas_access as mdb Is this a different file? If so, have you os.chdir()ed back to the working directory? If not, it's considered good practice to put all your 'import' statements at the top of the file. > # Listing the tables. > for tbl in mdb.list_tables('FB4-DXA-C2-BSL.mdb'): > print(tbl) > > > # Read a small table. > df =mdb.read_table('FB4-DXA-C2-BSL.mdb', "Patient") > > i am getting this error > > WinError 2] The system cannot find the file specified I'm sure Python printed out a whole lot more information than that, including the line of code that caused the problem. It would help if you gave us the entire traceback (from the line beginning "Traceback"). Please copy and paste the text; don't try to transcribe it or take a screen shot! -- Rhodri James *-* Kynesim Ltd From python at mrabarnett.plus.com Tue Feb 5 08:02:17 2019 From: python at mrabarnett.plus.com (MRAB) Date: Tue, 5 Feb 2019 13:02:17 +0000 Subject: [Python-ideas] need python automation code convert MDB files into csv files. In-Reply-To: <51b9000f-e24a-e037-80cd-1cff559da9df@kynesim.co.uk> References: <643e5924-87cb-492c-b8a5-1a1f69cfd87c@googlegroups.com> <51b9000f-e24a-e037-80cd-1cff559da9df@kynesim.co.uk> Message-ID: On 2019-02-05 11:42, Rhodri James wrote: > On 05/02/2019 00:10, vinoth A N wrote: [snip] >> extension = 'mdb' >> result = [i for i in glob.glob('*.{}'.format(extension))] > > Not a bug, but you are making unnecessary work for yourself here. > 'extension' is only ever the string "mdb", so why go to all the trouble > of formatting it into a string when you could just write: > > result = [i for i in glob.glob('*.mdb')] > You can do better than that. glob returns a list! [snip] From rhodri at kynesim.co.uk Tue Feb 5 08:13:55 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Tue, 5 Feb 2019 13:13:55 +0000 Subject: [Python-ideas] need python automation code convert MDB files into csv files. In-Reply-To: References: <643e5924-87cb-492c-b8a5-1a1f69cfd87c@googlegroups.com> <51b9000f-e24a-e037-80cd-1cff559da9df@kynesim.co.uk> Message-ID: <93b3be3f-a5a3-defb-0528-dc79d009c3c4@kynesim.co.uk> On 05/02/2019 13:02, MRAB wrote: > On 2019-02-05 11:42, Rhodri James wrote: >> On 05/02/2019 00:10, vinoth A N wrote: > [snip] >>> extension = 'mdb' >>> result = [i for i in glob.glob('*.{}'.format(extension))] >> >> Not a bug, but you are making unnecessary work for yourself here. >> 'extension' is only ever the string "mdb", so why go to all the trouble >> of formatting it into a string when you could just write: >> >> ??? result = [i for i in glob.glob('*.mdb')] >> > You can do better than that. glob returns a list! Duh! Good point. -- Rhodri James *-* Kynesim Ltd From lele at metapensiero.it Tue Feb 5 13:10:06 2019 From: lele at metapensiero.it (Lele Gaifax) Date: Tue, 05 Feb 2019 19:10:06 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL References: <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> <20190203112411.GV1834@ando.pearwood.info> Message-ID: <87pns63y4h.fsf@metapensiero.it> Steven D'Aprano writes: > One readline feature I know of which I would love to see supported in > the REPL is the "execute and next line" command. On my bash system, it > is Ctrl-O. I implemented and offered the feature, but unfortunately it is just a couple of lines copied from bash, and that being GPL was considered unfair to be relicensed under current Python license. Maybe sooner or later I will try to repackage it as a standalone extension. ciao, lele. -- nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. lele at metapensiero.it | -- Fortunato Depero, 1929. From lele at metapensiero.it Wed Feb 6 02:19:06 2019 From: lele at metapensiero.it (Lele Gaifax) Date: Wed, 06 Feb 2019 08:19:06 +0100 Subject: [Python-ideas] Option of running shell/console commands inside the REPL References: <87k1ijep5n.fsf@metapensiero.it> <20190201184450.GV1834@ando.pearwood.info> <20190201203121.yffztjtoxdbczmnc@phdru.name> <20190202131334.oca4kojgegyxuh73@phdru.name> <20190203112411.GV1834@ando.pearwood.info> <87pns63y4h.fsf@metapensiero.it> Message-ID: <87bm3pz8np.fsf@metapensiero.it> Lele Gaifax writes: > Steven D'Aprano writes: > >> One readline feature To be exact, it's not a feature of the readline library: see https://bugs.python.org/issue22228 (sigh, my GH fork of cpython has been recreated so some refs are broken). ciao, lele. -- nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. lele at metapensiero.it | -- Fortunato Depero, 1929. From steve at pearwood.info Thu Feb 7 00:02:52 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 7 Feb 2019 16:02:52 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> Message-ID: <20190207050252.GC1834@ando.pearwood.info> Before I respond to a specific point below, I'd like to make a general observation. I changed the subject line of this sub-thread to discuss a feature of Julia, which allows one to write vectorized code in standard infix arithmetic notation, that applies to any array type, using any existing function or operator, WITHOUT having to wrap your data in a special delegate class like this "Vector". So as far as I'm concerned, this entire discussion about this wrapper class misses the point. (Aside: why is this class called "Vector" when it doesn't implement a vector?) Anyway, on to my response to a specific point: On Mon, Feb 04, 2019 at 11:12:08AM -0500, David Mertz wrote: > On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov > wrote: > > > len(v) # -> 12 > > > > v[len] # -> > > > > > > In this case you can apply any function, even custom_linked_list from > > my_inhouse_module.py. > > > > I think I really like this idea. Maybe as an extra spelling but still > allow .apply() to do the same thing. It feels reasonably intuitive to me. > Not *identical to* indexing in NumPy and Pandas, but sort of in the same > spirit as predicative or selection based indices. > > What do other people on this thread think? Would you learn that easily? obj[len] already has an established meaning as obj.__getitem__(len). There's going to be clash here between key lookup and applying a function: obj[len] # look up key=len obj[len] # apply function len Mathematica does use square brackets for calling functions, but it uses ordinary arithmetic order len[obj] rather than postfix order obj[len]. At the risk of causing confusion^1, we could have a "vector call" syntax: # apply len to each element of obj, instead of obj itself len[obj] which has the advantage that it only requires that we give functions a __getitem__ method, rather than adding new syntax. But it has the disadvantage that it doesn't generalise to operators, without which I don't think this is worth bothering with. ^1 Cue a thousand Stackoverflow posts asking whether they should use round brackets or square when calling a function, and why they get weird error messages sometimes and not other times. -- Steven From steve at pearwood.info Thu Feb 7 00:13:31 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 7 Feb 2019 16:13:31 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <3C6E30CF-0A9E-4309-9790-F88CB8A0B480@mac.com> Message-ID: <20190207051330.GD1834@ando.pearwood.info> On Sun, Feb 03, 2019 at 09:46:44PM -0800, Christopher Barker wrote: > I've lost track if who is advocating what, but: Ironically, I started this sub-thread in response to your complaint that you didn't like having to explicitly write loops/maps. So I pointed out that in Julia, people can use (almost) ordinary infix syntax using operators and function calls and have it apply automatically to each item in arrays. It wasn't a concrete proposal, just food for thought. Unfortunately the thinking seems to have missed the point of the Julia syntax and run off with the idea of a wrapper class. [...] > I do not get the point of this at all -- we already have map" > > map(v, lambda s s.replace()"a,", "b") The order of arguments is the other way around. And you did say you didn't like map. Wouldn't you rather write: items.replace("a", "b") rather than map(lambda s: s.replace("a", "b"), items) or [s.replace("a", "b") for s in items] I know I would. Provided of course we could distinguish between operations which apply to a single string, and those which apply to a generic collection of strings. Beside, while a single map or comprehension is bearable, more complex operations are horrible to read when written that way, but trivially easy to read when written in standard infix arithmetic notation. See my earlier posts for examples. > > v.replace("a", "b") > > > > This is adding something - maybe just compactness, but I also think > readability. Indeed. In Julia that also offers opportunities for the compiler to optimize the code, bringing it to within 10% or so of a C loop. Maybe PyPy could get there as well, but CPython probably can't. > I've also lost track of whether anyone is proposing a "vector of strings' > as opposed to a vector of arbitrary objects. Not me. -- Steven From rosuav at gmail.com Thu Feb 7 00:27:08 2019 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 7 Feb 2019 16:27:08 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190207050252.GC1834@ando.pearwood.info> References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <20190207050252.GC1834@ando.pearwood.info> Message-ID: On Thu, Feb 7, 2019 at 4:03 PM Steven D'Aprano wrote: > At the risk of causing confusion^1, we could have a "vector call" > syntax: > > # apply len to each element of obj, instead of obj itself > len[obj] > > which has the advantage that it only requires that we give functions a > __getitem__ method, rather than adding new syntax. But it has the > disadvantage that it doesn't generalise to operators, without which I > don't think this is worth bothering with. Generalizing to operators is definitely going to require new syntax, since both operands can be arbitrary objects. So if that's essential to the idea, we can instantly reject anything that's based on functions (like "make multiplying a function by a tuple equivalent to blah blah blah"). In that case, we come straight to a few key questions: 1) Is this feature even worth adding syntax for? (My thinking: "quite possibly", based on matmul's success despite having an even narrower field of use than this.) 2) Should it create a list? a generator? something that depends on the type of the operand? (Me: "no idea") 2) Does the Julia-like "x." syntax pass the grit test? (My answer: "nope") 3) If not, what syntax would be more appropriate? This is a general purpose feature akin to comprehensions (and, in fact, can be used in place of some annoyingly-verbose comprehensions). It needs to be easy to type and read. Pike's automap syntax is to subscript an array with [*], implying "subscript this with every possible value". It's great if you want to do just one simple thing: f(stuff[*]) # [f(x) for x in stuff] stuff[*][1] # [x[1] for x in stuff] but clunky for chained operations: (f(stuff[*])[*] * 3)[*] + 1 # [f(x) * 3 + 1 for x in stuff] That might not be a problem in Python, since you can always just use a comprehension if vectorized application doesn't suit you. I kinda like the idea, but the devil's in the details. ChrisA From python-ideas at mgmiller.net Thu Feb 7 13:13:29 2019 From: python-ideas at mgmiller.net (Mike Miller) Date: Thu, 7 Feb 2019 10:13:29 -0800 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: <20180401004330.GX16661@ando.pearwood.info> References: <20180401004330.GX16661@ando.pearwood.info> Message-ID: <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Was: "Dart (Swift) like multi line strings indentation" This discussion petered-out but I liked the idea, as it alleviates something occasionally annoying. Am supportive of the d'' prefix, perhaps the capital prefixes can be deprecated to avoid issues? If not, a sometimes-optimized (or C-accelerated) str.dedent() is acceptable too. Anyone still interested in this? -Mike On 3/31/18 5:43 PM, Steven D'Aprano wrote: > The ideal solution would: > > - require only a single pair of starting/ending string delimiters; > > - allow string literals to be indented to the current block, for > the visual look and to make it more convenient with editors > which automatically indent; > > - evaluate without the indents; > > - with no runtime cost. > > > One solution is to add yet another string prefix, let's say d for > dedent, but as Terry and others point out, that leads to a combinational > explosion with f-strings and r-strings already existing. > > Another possibility is to make dedent a string method: > > def spam(): > text = """\ > some text > another line > and a third > """.dedent() > print(text) > > and avoid the import of textwrap. However, that also imposes a runtime > cost, which could be expensive if you are careless: > > for x in seq: > for y in another_seq: > process("""/ > some large indented string > """.dedent() > ) > > (Note: the same applies to using textwrap.dedent.) > > But we could avoid that runtime cost if the keyhole optimizer performed > the dedent at compile time: > > triple-quoted string literal > .dedent() > > could be optimized at compile-time, like other constant-folding. > > Out of all the options, including the status quo, the one I dislike the > least is the last one: > > - make dedent a string method; > > - recommend (but don't require) that implementations perform the > dedent of string literals at compile time; > > (failure to do so is a quality of implementation issue, not a bug) > > - textwrap.dedent then becomes a thin wrapper around the string method. On 4/1/18 4:41 AM, Michel Desmoulin wrote:> > A "d" prefix to do textwrap.dedent is something I wished for a long time. > > It's like the "f" one: we already can do it, be hell is it convenient to > have a shortcut. > > This is especially if, like me, you take a lot of care in the error > messages you give to the user. I write a LOT of them, very long, very > descriptive, and I have to either import textwrap or play the > concatenation game. > > Having a str.dedent() method would be nice, but the d prefix has the > huge advantage to be able to dedent on parsing, and hence be more > performant. > From python at mrabarnett.plus.com Thu Feb 7 13:30:29 2019 From: python at mrabarnett.plus.com (MRAB) Date: Thu, 7 Feb 2019 18:30:29 +0000 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <20190207050252.GC1834@ando.pearwood.info> Message-ID: On 2019-02-07 05:27, Chris Angelico wrote: > On Thu, Feb 7, 2019 at 4:03 PM Steven D'Aprano wrote: >> At the risk of causing confusion^1, we could have a "vector call" >> syntax: >> >> # apply len to each element of obj, instead of obj itself >> len[obj] >> >> which has the advantage that it only requires that we give functions a >> __getitem__ method, rather than adding new syntax. But it has the >> disadvantage that it doesn't generalise to operators, without which I >> don't think this is worth bothering with. > > Generalizing to operators is definitely going to require new syntax, > since both operands can be arbitrary objects. So if that's essential > to the idea, we can instantly reject anything that's based on > functions (like "make multiplying a function by a tuple equivalent to > blah blah blah"). In that case, we come straight to a few key > questions: > > 1) Is this feature even worth adding syntax for? (My thinking: "quite > possibly", based on matmul's success despite having an even narrower > field of use than this.) > > 2) Should it create a list? a generator? something that depends on the > type of the operand? (Me: "no idea") > > 2) Does the Julia-like "x." syntax pass the grit test? (My answer: "nope") > > 3) If not, what syntax would be more appropriate? > > This is a general purpose feature akin to comprehensions (and, in > fact, can be used in place of some annoyingly-verbose comprehensions). > It needs to be easy to type and read. > > Pike's automap syntax is to subscript an array with [*], implying > "subscript this with every possible value". It's great if you want to > do just one simple thing: > > f(stuff[*]) > # [f(x) for x in stuff] > stuff[*][1] > # [x[1] for x in stuff] > > but clunky for chained operations: > > (f(stuff[*])[*] * 3)[*] + 1 > # [f(x) * 3 + 1 for x in stuff] > > That might not be a problem in Python, since you can always just use a > comprehension if vectorized application doesn't suit you. > > I kinda like the idea, but the devil's in the details. > Would it be possible, at compile time, to retain it as an automap throughout the expression? stuff[*] # [x for x in suffix] f(stuff[*]) # [f(x) for x in stuff] (f(stuff[*]) * 3) + 1 # [f(x) * 3 + 1 for x in stuff] There could also be a way to 'collapse' it again. An uncollapsed automap would be collapsed at the end of the expression. (Still a bit fuzzy about the details...) From jamtlu at gmail.com Thu Feb 7 14:18:42 2019 From: jamtlu at gmail.com (James Lu) Date: Thu, 7 Feb 2019 14:18:42 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <20190207050252.GC1834@ando.pearwood.info> Message-ID: <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> Here are some alternate syntaxes. These are all equivalent to len(print(list)). (len | print)(list) (len |> print)(list) (print <| len)(list) print <| len << list list >> print <| len list >> len |> print ## Traditional argument order print <| len << list ## Stored functions print_lengths = len | print print_lengths = len |> print print_lengths = print <| len These can be called using callable syntax. These can be called using << syntax. These can be called using >> syntax. ## Lightweight traditional syntax order (print | len)() # Explanation The pipeline operator (|, |>, <|) create an object. That object implements, depending on the chosen implementation, some combination of the __call__ operator, the __rshift__ operator, and/or the __lshift__ operator. ? I am not proposing Python has all these operators at the same time, just putting these ideas out there for discussion. From mertz at gnosis.cx Thu Feb 7 15:17:18 2019 From: mertz at gnosis.cx (David Mertz) Date: Thu, 7 Feb 2019 15:17:18 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> References: <8d95dd79-4389-3e77-4d19-b3596fffd306@mrabarnett.plus.com> <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> Message-ID: Many apologies if people got one or more encrypted versions of this. On 2/7/19 12:13 AM, Steven D'Aprano wrote: It wasn't a concrete proposal, just food for thought. Unfortunately the thinking seems to have missed the point of the Julia syntax and run off with the idea of a wrapper class. I did not miss the point! I think adding new syntax ? la Julia is a bad idea?or at very least, not something we can experiment with today (and wrote as much). Therefore, something we CAN think about and experiment with today is a wrapper class. This approach is pretty much exactly the same thing I tried in a discussion of PEP 505 a while back (None-aware operators). In the same vein as that?where I happen to dislike PEP 505 pretty strongly?one approach to simulate or avoid new syntax is precisely to use a wrapper class. As a footnote, I think my demonstration of PEP 505 got derailed by lots of comments along the lines of "Your current toy library gets the semantics of the proposed new syntax wrong in these edge cases." Those comments were true (and I think I didn't fix all the issues since my interest faded with the active thread)... but none of them were impossible to fix, just small errors I had made. With my *very toy* stringpy.Vector class, I'm just experimenting with usage ideas. I have shown a number of uses that I think could be useful to capture most or all of what folks want in "string vectorization." Most of what I've but in this list is what the little module does already, but some is just ideas for what it might do if I add the code (or someone else makes a PR at https://github.com/DavidMertz/stringpy). One of the principles I had in mind in my demonstration is that I want to wrap the original collection type (or keep it an iterator if it started as one). A number of other ideas here, whether for built-in syntax or different behaviors of a wrapper, effectively always reduce every sequence to a list under the hood. This makes my approach less intrusive to move things in and out of "vector mode." For example: v1 = Vector(set_of_strings) set_of_strings = v1.lower().apply(my_str_fun)._it # Get a set back v2 = Vector(list_of_strings) list_of_strings = v2.lower().apply(my_str_fun)._it # Get a list back v3 = Vector(deque_of_strings) deque_of_strings = v3.lower().apply(my_str_fun)._it # Get a deque back v4 = Vector(iter_of_strings) iter_of_strings = v4.lower().apply(my_str_fun)._it # stays lazy! So this is round-tripping through vector-land. Small note: I use the attribute `._it` to store the "sequential thing." That feels internal, so maybe some better way of spelling "get the wrapped thing" would be desirable. I've also lost track of whether anyone is proposing a "vector of strings' as opposed to a vector of arbitrary objects. Nothing I wrote is actually string-specific. That is just the main use case stated. My `stringpy.Vector` might be misnamed in that it is happy to contain any kind of items. But we hope they are all items with the particular methods we want to vectorize. I showed an example where a list might contain a custom string-like object that happens to have methods like `.lower()` as an illustration. Inasmuch as I want to handle iterator here, it is impossible to do any type check upon creating a Vector. For concrete `collections.abc.Sequence` objects we could check, in principle. But I'd rather it be "we're all adults here" ... or at most provide some `check_type_uniformity()` function or method that had to be called explicitly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Thu Feb 7 18:42:00 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 8 Feb 2019 10:42:00 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> Message-ID: <20190207234200.GI1834@ando.pearwood.info> On Thu, Feb 07, 2019 at 03:17:18PM -0500, David Mertz wrote: > Many apologies if people got one or more encrypted versions of this. > > On 2/7/19 12:13 AM, Steven D'Aprano wrote: > > It wasn't a concrete proposal, just food for thought. Unfortunately the > thinking seems to have missed the point of the Julia syntax and run off > with the idea of a wrapper class. > > I did not miss the point! I think adding new syntax ? la Julia is a bad > idea?or at very least, not something we can experiment with today (and > wrote as much). I'm sorry, I did not see your comment that you thought new syntax was a bad idea. If I had, I would have responded directly to that. Why is it an overtly *bad* (i.e. harmful) idea? As opposed to merely not sufficiently useful, or unnecessary? You're certainly right that we can't easily experiment in the interpreter with new syntax, but we can perform thought-experiments and we don't need anything but a text editor for that. As far as I'm concerned, the thought experiment of comparing these two snippets: ((seq .* 2)..name)..upper() versus map(str.upper, map(operator.attrgetter('name'), map(lambda a: a*2, seq))) demonstrates conclusively that even with the ugly double dot syntax, infix syntax easily and conclusively beats map. If I recall correctly, the three maps here were originally proposed by you as examples of why map() alone was sufficient and there was no benefit to the Julia syntax. I suggested composing them together as a single operation instead of considering them in isolation. > Therefore, something we CAN think about and experiment with today is a > wrapper class. Again, I apologise, I did not see where you said that this was intended as a proof-of-concept to experiment with the concept. [...] > One of the principles I had in mind in my demonstration is that I want > to wrap the original collection type (or keep it an iterator if it > started as one). A number of other ideas here, whether for built-in > syntax or different behaviors of a wrapper, effectively always reduce > every sequence to a list under the hood. This makes my approach less > intrusive to move things in and out of "vector mode." For example: If the Vector class is only a proof of concept, then we surely don't need to care about moving things in and out of "vector mode". We can take it as a given that "the real thing" will work that way: the syntax will be duck-typed and work with any iterable, and there will not be any actual wrapper class involved and consequently no need to move things in and out of the wrapper. I had taken note of this functionality of the class before, and that was one of the things which lead me to believe that you thought that a wrapper class was in and of itself a solution to the problem. If you had been proposing this Vector class as a viable working solution (or at least a first alpha version towards a viable solution) then worrying about round-tripping would be important. But as a proof-of-concept of the functionality, then: set( Vector(set_of_stuff) + spam ) list( Vector(list_of_stuff) + spam ) should be enough to play around with the concept. [...] > Inasmuch as I want to handle iterator here, it is impossible to do any > type check upon creating a Vector. For concrete > `collections.abc.Sequence` objects we could check, in principle. But > I'd rather it be "we're all adults here" ... or at most provide some > `check_type_uniformity()` function or method that had to be called > explicitly. Why do you care about type uniformity or type-checking the contents of the iterable? Comments like this suggest to me that you haven't understood the idea as I have tried to explain it. I'm sorry that I have failed to explain it better. Julia is (if I understand correctly) statically typed, and that allows it to produce efficient machine code because it knows that it is iterating over (let's say) an array of 32-bit ints. While that might be important for the efficiency of the generated machine code, that's not important for the semantic meaning of the code. In Python, we duck-type and resolve operations at runtime. We don't typically validate types in advance: for x in sequence: if not isinstance(x, Spam): raise TypeError('not Spam') for x in sequence: process(x) (except under unusual circumstances). More to the point, when we write a for-loop: result = [] for a_string in seq: result.append(a_string.upper()) we don't expect that the interpreter will validate that the sequence contains nothing but strings in advance. So if I write this using Julia syntax: result = seq..upper() I shouldn't expect the iterpreter to check that seq contains nothing but strings either. -- Steven From mertz at gnosis.cx Thu Feb 7 19:26:31 2019 From: mertz at gnosis.cx (David Mertz) Date: Thu, 7 Feb 2019 19:26:31 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190207234200.GI1834@ando.pearwood.info> References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> <20190207234200.GI1834@ando.pearwood.info> Message-ID: On Thu, Feb 7, 2019 at 6:48 PM Steven D'Aprano wrote: > I'm sorry, I did not see your comment that you thought new syntax was a > bad idea. If I had, I would have responded directly to that. > Well... I don't think it's the worst idea ever. But in general adding more operators is something I am generally wary about. Plus there's the "grit on Uncle Timmy's screen" test. Actually, if I wanted an operator, I think that @ is more intuitive than extra dots. Vectorization isn't matrix multiplication, but they are sort of in the same ballpark, so the iconography is not ruined. > We can perform thought-experiments and > we don't need anything but a text editor for that. As far as I'm > concerned, the thought experiment of comparing these two snippets: > > ((seq .* 2)..name)..upper() > > versus > > map(str.upper, map(operator.attrgetter('name'), map(lambda a: a*2, > seq))) > OK... now compare: (Vec(seq) * 2).name.upper() Or: vec_seq = Vector(seq) (vec_seq * 2).name.upper() # ... bunch more stuff seq = vec_seq.unwrap() I'm not saying the double dots are terrible, but they don't read *better* than wrapping (and optionally unwrapping) to me. If we were to take @ as "vectorize", it might be: (seq @* 2) @.name @.upper() I don't hate that. demonstrates conclusively that even with the ugly double dot syntax, > infix syntax easily and conclusively beats map. > Agreed. > If I recall correctly, the three maps here were originally proposed by > you as examples of why map() alone was sufficient and there was no > benefit to the Julia syntax. Well... your maps are kinda deliberately ugly. Even in that direction, I'd write: map(lambda s: (s*2).name.upper(), seq) I don't *love* that, but it's a lot less monstrous than what you wrote. A comprehension probably even better: [(s*2).name.upper() for s in seq] Again, I apologise, I did not see where you said that this was intended > as a proof-of-concept to experiment with the concept. > All happy. Puppies and flowers. > If the Vector class is only a proof of concept, then we surely don't > need to care about moving things in and out of "vector mode". We can > take it as a given that "the real thing" will work that way: the syntax > will be duck-typed and work with any iterable, Well... I at least moderately think that a wrapper class is BETTER than new syntax. So I'd like the proof-of-concept to be at least moderately functional. In any case, there is ZERO code needed to move in/out of "vector mode." The wrapped thing is simply an attribute of the object. When we call vectorized methods, it's just `getattr(type(item), attr)` to figure out the method in a duck-typed way. one of the things which lead me to believe that you thought that a > wrapper class was in and of itself a solution to the problem. If you had > been proposing this Vector class as a viable working solution (or at > least a first alpha version towards a viable solution) then worrying > about round-tripping would be important. > Yes, I consider the Vector class a first alpha version of a viable solution. I haven't seen anything that makes me prefer new syntax. I feel like a wrapper makes it more clear that we are "living in vector land" for a while. The same is true for NumPy, in my mind. Maybe it's just familiarity, but I LIKE the fact that I know that when my object is an ndarray, operations are going to be vectorized ones. Maybe 15 years ago different decisions could have been made, and some "vectorize this operation syntax" could have made the ndarray structure just a behavior of lists instead. But I think the separation is nice. > But as a proof-of-concept of the functionality, then: > > set( Vector(set_of_stuff) + spam ) > list( Vector(list_of_stuff) + spam ) > That's fine. But there's no harm in the class *remembering* what it wraps either. We might want to distinguish: set(Vector(some_collection) + spam) # Make it a set after the operations (Vector(some_collection) + spam).unwrap() # Recover whatever type it was before > Why do you care about type uniformity or type-checking the contents of > the iterable? > Because some people have said "I want my vector to be specifically a *sequence of strings* not of other stuff" And MAYBE there is some optimization to be had if we know we'll never have a non-footype in the sequence (after all, NumPy is hella optimized). That's why the `stringpy` name that someone suggested. Maybe we'd bypass most of the Python-land calls when we did the vectorized operations, but ONLY if we assume type uniformity. But yes, I generally care about duck-typing only. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Fri Feb 8 07:59:37 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 8 Feb 2019 23:59:37 +1100 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: <20190208125936.GM1834@ando.pearwood.info> On Thu, Feb 07, 2019 at 10:13:29AM -0800, Mike Miller wrote: > Was: "Dart (Swift) like multi line strings indentation" [...] > Anyone still interested in this? I am, but it will surely need a PEP. I'm not interested enough to write the PEP itself but I'm more than happy to tear it to bits^W^W^W er I mean offer constructive criticism and/or support. -- Steven From pflarr at gmail.com Fri Feb 8 10:26:01 2019 From: pflarr at gmail.com (Paul Ferrell) Date: Fri, 8 Feb 2019 08:26:01 -0700 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: I particularly like the str.dedent() idea. Adding yet another string prefix adds more complexity to the language, which I'm generally not in favor of. On 2/7/19, Mike Miller wrote: > Was: "Dart (Swift) like multi line strings indentation" > > This discussion petered-out but I liked the idea, as it alleviates something > > occasionally annoying. > > Am supportive of the d'' prefix, perhaps the capital prefixes can be > deprecated > to avoid issues? If not, a sometimes-optimized (or C-accelerated) > str.dedent() > is acceptable too. > > Anyone still interested in this? > > -Mike > > > > On 3/31/18 5:43 PM, Steven D'Aprano wrote: >> The ideal solution would: >> >> - require only a single pair of starting/ending string delimiters; >> >> - allow string literals to be indented to the current block, for >> the visual look and to make it more convenient with editors >> which automatically indent; >> >> - evaluate without the indents; >> >> - with no runtime cost. >> >> >> One solution is to add yet another string prefix, let's say d for >> dedent, but as Terry and others point out, that leads to a combinational >> explosion with f-strings and r-strings already existing. >> >> Another possibility is to make dedent a string method: >> >> def spam(): >> text = """\ >> some text >> another line >> and a third >> """.dedent() >> print(text) >> >> and avoid the import of textwrap. However, that also imposes a runtime >> cost, which could be expensive if you are careless: >> >> for x in seq: >> for y in another_seq: >> process("""/ >> some large indented string >> """.dedent() >> ) >> >> (Note: the same applies to using textwrap.dedent.) >> >> But we could avoid that runtime cost if the keyhole optimizer performed >> the dedent at compile time: >> >> triple-quoted string literal >> .dedent() >> >> could be optimized at compile-time, like other constant-folding. >> >> Out of all the options, including the status quo, the one I dislike the >> least is the last one: >> >> - make dedent a string method; >> >> - recommend (but don't require) that implementations perform the >> dedent of string literals at compile time; >> >> (failure to do so is a quality of implementation issue, not a bug) >> >> - textwrap.dedent then becomes a thin wrapper around the string method. > > > > On 4/1/18 4:41 AM, Michel Desmoulin wrote:> > > A "d" prefix to do textwrap.dedent is something I wished for a long > time. > > > > It's like the "f" one: we already can do it, be hell is it convenient to > > have a shortcut. > > > > This is especially if, like me, you take a lot of care in the error > > messages you give to the user. I write a LOT of them, very long, very > > descriptive, and I have to either import textwrap or play the > > concatenation game. > > > > Having a str.dedent() method would be nice, but the d prefix has the > > huge advantage to be able to dedent on parsing, and hence be more > > performant. > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Paul Ferrell pflarr at gmail.com From jsbueno at python.org.br Fri Feb 8 10:48:12 2019 From: jsbueno at python.org.br (Joao S. O. Bueno) Date: Fri, 8 Feb 2019 13:48:12 -0200 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: /me also would be strongly in favor of this. "+1 " . Even taking in consideration the added complexity . On Fri, 8 Feb 2019 at 13:26, Paul Ferrell wrote: > I particularly like the str.dedent() idea. Adding yet another string > prefix adds more complexity to the language, which I'm generally not > in favor of. > > On 2/7/19, Mike Miller wrote: > > Was: "Dart (Swift) like multi line strings indentation" > > > > This discussion petered-out but I liked the idea, as it alleviates > something > > > > occasionally annoying. > > > > Am supportive of the d'' prefix, perhaps the capital prefixes can be > > deprecated > > to avoid issues? If not, a sometimes-optimized (or C-accelerated) > > str.dedent() > > is acceptable too. > > > > Anyone still interested in this? > > > > -Mike > > > > > > > > On 3/31/18 5:43 PM, Steven D'Aprano wrote: > >> The ideal solution would: > >> > >> - require only a single pair of starting/ending string delimiters; > >> > >> - allow string literals to be indented to the current block, for > >> the visual look and to make it more convenient with editors > >> which automatically indent; > >> > >> - evaluate without the indents; > >> > >> - with no runtime cost. > >> > >> > >> One solution is to add yet another string prefix, let's say d for > >> dedent, but as Terry and others point out, that leads to a combinational > >> explosion with f-strings and r-strings already existing. > >> > >> Another possibility is to make dedent a string method: > >> > >> def spam(): > >> text = """\ > >> some text > >> another line > >> and a third > >> """.dedent() > >> print(text) > >> > >> and avoid the import of textwrap. However, that also imposes a runtime > >> cost, which could be expensive if you are careless: > >> > >> for x in seq: > >> for y in another_seq: > >> process("""/ > >> some large indented string > >> """.dedent() > >> ) > >> > >> (Note: the same applies to using textwrap.dedent.) > >> > >> But we could avoid that runtime cost if the keyhole optimizer performed > >> the dedent at compile time: > >> > >> triple-quoted string literal > >> .dedent() > >> > >> could be optimized at compile-time, like other constant-folding. > >> > >> Out of all the options, including the status quo, the one I dislike the > >> least is the last one: > >> > >> - make dedent a string method; > >> > >> - recommend (but don't require) that implementations perform the > >> dedent of string literals at compile time; > >> > >> (failure to do so is a quality of implementation issue, not a bug) > >> > >> - textwrap.dedent then becomes a thin wrapper around the string method. > > > > > > > > On 4/1/18 4:41 AM, Michel Desmoulin wrote:> > > > A "d" prefix to do textwrap.dedent is something I wished for a long > > time. > > > > > > It's like the "f" one: we already can do it, be hell is it convenient > to > > > have a shortcut. > > > > > > This is especially if, like me, you take a lot of care in the error > > > messages you give to the user. I write a LOT of them, very long, very > > > descriptive, and I have to either import textwrap or play the > > > concatenation game. > > > > > > Having a str.dedent() method would be nice, but the d prefix has the > > > huge advantage to be able to dedent on parsing, and hence be more > > > performant. > > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > -- > Paul Ferrell > pflarr at gmail.com > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Fri Feb 8 11:18:51 2019 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 8 Feb 2019 16:18:51 +0000 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: On Thu, 7 Feb 2019 at 18:21, Mike Miller wrote: > Anyone still interested in this? It feels like a nice idea to me, when reading the proposals. However, in all of the code I've ever written in Python (and that's quite a lot...) I've never actually had a case where I this feature would have made a significant difference to the code I wrote. Maybe that says more about my coding style than about the usefulness of the feature, but personally I don't think it's worth it. Paul PS Although I could probably have said something similar about f-strings, and now I use them all the time. Language design is hard ;-) From rosuav at gmail.com Fri Feb 8 11:28:14 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 9 Feb 2019 03:28:14 +1100 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: On Sat, Feb 9, 2019 at 3:19 AM Paul Moore wrote: > > On Thu, 7 Feb 2019 at 18:21, Mike Miller wrote: > > Anyone still interested in this? > > It feels like a nice idea to me, when reading the proposals. However, > in all of the code I've ever written in Python (and that's quite a > lot...) I've never actually had a case where I this feature would have > made a significant difference to the code I wrote. Maybe that says > more about my coding style than about the usefulness of the feature, > but personally I don't think it's worth it. > > Paul > > PS Although I could probably have said something similar about > f-strings, and now I use them all the time. Language design is hard > ;-) Yeah, no kidding :-) If someone wants to push this further, I'm happy to assist with the mechanics of writing up a PEP. From my memory, the leading proposals were: 1) Creating a new type of string literal which compiles to a dedented form of multiline string 2a) Adding a str.dedent() method 2b) Creating a constant-folding peephole optimization for methods on immutable literals Either way, the definition of "dedent" would be identical to textwrap.dedent(), meaning that if 2a were to happen, that function could simply "return text.dedent()". Who wants to champion this proposal? ChrisA From python-ideas at mgmiller.net Fri Feb 8 14:07:17 2019 From: python-ideas at mgmiller.net (Mike Miller) Date: Fri, 8 Feb 2019 11:07:17 -0800 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: <55971749-4618-6969-0c7a-152063c4be4a@mgmiller.net> Thanks all, I'm willing to start work on a PEP, perhaps next week. Unless Marius would prefer to do it. One fly in the ointment is that I don't feel strongly about the choice of solution 1, 2, or last-minute entry. -Mike From rosuav at gmail.com Fri Feb 8 14:11:35 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 9 Feb 2019 06:11:35 +1100 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: <55971749-4618-6969-0c7a-152063c4be4a@mgmiller.net> References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> <55971749-4618-6969-0c7a-152063c4be4a@mgmiller.net> Message-ID: On Sat, Feb 9, 2019 at 6:08 AM Mike Miller wrote: > > Thanks all, > > I'm willing to start work on a PEP, perhaps next week. Unless Marius would > prefer to do it. > > One fly in the ointment is that I don't feel strongly about the choice of > solution 1, 2, or last-minute entry. > That's not a problem. You can write up the arguments for and against each side fairly, and let them convince you. Early phases of PEPs don't have to have all the specifics set in concrete. Marius or Mike, whoever's going to do this: you'll want to start by reading through PEP 12, taking a copy of that file as a template. https://www.python.org/dev/peps/pep-0012/ https://raw.githubusercontent.com/python/peps/master/pep-0012.rst Feel free to reach out to me or any of the other PEP editors if you need a hand with the mechanics. ChrisA From pythonchb at gmail.com Fri Feb 8 14:56:02 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Fri, 8 Feb 2019 11:56:02 -0800 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: not that anyone asked, but I"d only support: > 2a) Adding a str.dedent() method and maybe: > 2b) Creating a constant-folding peephole optimization for methods on immutable literals and frankly, it's a much lighter lift to get approval than: 1) Creating a new type of string literal which compiles to a dedented form of multiline string Also -- more useful -- dedent() is helpful for non-literals as well. Other than docstrings, the case for literals is pretty small, and docstrings are already auto-cleaned up. > in all of the code I've ever written in Python (and that's quite a > > lot...) I've never actually had a case where I this feature would have > > made a significant difference to the code I wrote. exactly -- I do have one case -- but that's for an instructional exercise where we are keeping things simple -- in operational code that string would have been in a file, or database, or .... -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Fri Feb 8 15:16:05 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Fri, 8 Feb 2019 12:16:05 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> <20190207234200.GI1834@ando.pearwood.info> Message-ID: On Thu, Feb 7, 2019 at 4:27 PM David Mertz wrote: > Actually, if I wanted an operator, I think that @ is more intuitive than extra dots. Vectorization isn't matrix multiplication, but they are sort of in the same ballpark, so the iconography is not ruined. well, vectorization is kinda the *opposite* of matrix multiplication -- matrix multiplication is treating the matrix as a whole, rther than applying multiplication to each element. And it is certainly the opposite in the numpy case. Which gives me an idea -- we could make an object that applied operators (and methods??) to each element individually, and use the @ operator when you wanted the method to act on the whole object instead. Note: I haven't thought about the details at all -- may not be practical to use an operator for that. > (Vec(seq) * 2).name.upper() > Or: > vec_seq = Vector(seq) > (vec_seq * 2).name.upper() > # ... bunch more stuff > seq = vec_seq.unwrap() what type would .unwrap() return? One of the strengths of the "operator" approach is that is could apply to any (appropriately mutable) sequence and keep that sequence. I"m not sure how much that actually matters, as I'm expecting this is a 99% list case anyway. and why would .unwrap() be required at all -- as opposed to say: seq = list(vec_seq) > I'm not saying the double dots are terrible, but they don't read *better* than wrapping (and optionally unwrapping) to me. nor to me. > Well... your maps are kinda deliberately ugly. That's actually pretty key -- in fact, if you wanted to apply a handful of operations to each item in a sequence, you would probably use a single expression (If possible) in a lambda in a map, or in a comprehension, rather than chaining the map. Even if it was more complex, you could write a function, and then apply that with a map or comprehension. In the numpy case, compare: c = sqrt(a**2 + b**2) to c = [sqrt(a**2 + b**2) for a,b in zip(a,b)] so still a single comprehension. But: 1) given the familiariy of math expressions -- the first really does read a LOT better 2) the first version can be better optimized (by numpy) So the questions becomes: * For other than math with numbers (which we have numpy for), are there use cases where we'd really get that much extra clarity? * Could we better optimize, say, a sequence of strings enough to make it all worth it? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Fri Feb 8 15:35:31 2019 From: mertz at gnosis.cx (David Mertz) Date: Fri, 8 Feb 2019 15:35:31 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> <20190207234200.GI1834@ando.pearwood.info> Message-ID: On Fri, Feb 8, 2019 at 3:17 PM Christopher Barker wrote: > > vec_seq = Vector(seq) > > (vec_seq * 2).name.upper() > > # ... bunch more stuff > > seq = vec_seq.unwrap() > > what type would .unwrap() return? > The idea?and the current toy implementation/alpha?has .unwrap return whatever type went into the Vector creation. Might be a tuple, list, set, deque, or it might be an iterator. It might even be some custom collection that isn't in the standard library. But you can also explicitly make a Vector into something else by using that constructor. Pretty much as I gave example before: set(Vector(a_list)) # Get a set Vector(a_list)).unwrap() # Get a list (without needing to know type to call .unwrap()) -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benrudiak at gmail.com Fri Feb 8 16:30:58 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Fri, 8 Feb 2019 13:30:58 -0800 Subject: [Python-ideas] Multi-line string indentation In-Reply-To: <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> References: <20180401004330.GX16661@ando.pearwood.info> <6803a9ab-8055-035f-ee93-10d5733f6510@mgmiller.net> Message-ID: > On 3/31/18 5:43 PM, Steven D'Aprano wrote: > > But we could avoid that runtime cost if the keyhole optimizer performed > > the dedent at compile time: > > > > triple-quoted string literal > > .dedent() > > > > could be optimized at compile-time, like other constant-folding. There are a lot of expressions of the form constexpr.method(constexpr) that could be safely evaluated at compile time and currently aren't. It also occurred to me that if there were a set.frozen method returning a frozenset, then (with compiler support) you could write frozenset literals without new syntax. And if dict.get and dict.__getitem__ (including the operator syntax for the latter) made compile-time (frozen)dict literals the way "in {...}" already makes frozenset literals, it would give you a functional O(1) switch statement for some simple cases. -- Ben From jamtlu at gmail.com Fri Feb 8 17:15:54 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 8 Feb 2019 17:15:54 -0500 Subject: [Python-ideas] Keeping discussion relevant Message-ID: <8AA01359-7CA7-432F-B2EE-13DA4EF8A6B9@gmail.com> Sometimes I see threads briefly go into topics that are unrelated to new features in Python. For example: talking about a writer?s use of ?inhomogeneous? vs ?heterogenous? vs ?anhomogenous.? We get what the original author meant, there is no need to fiddle with the little details of language at this point, even if it is fun. These extra emails, though harmless, impose a visual, time, and navigational burden on the readers of the thread. It?s okay if the problem is little but not if it?s big. Two questions: How often does off-topic discussion occur? Does it need to be find ways to reduce the amount? How can we find ways to reduce the amount? From jamtlu at gmail.com Fri Feb 8 17:11:21 2019 From: jamtlu at gmail.com (James Lu) Date: Fri, 8 Feb 2019 17:11:21 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> <20190207234200.GI1834@ando.pearwood.info> Message-ID: <81FC967C-DEB6-476E-877B-376D768E23A6@gmail.com> Has anyone thought about my proposal yet? I think because it allows chained function calls to be stored, which is probably something that is a common; if imagine people turning the same series of chained functions into a lambda of its own once it?s used more than once in a program. Arguably, the lambda syntax is more readable and puts on less visual burden. Sent from my iPhone > On Feb 8, 2019, at 3:35 PM, David Mertz wrote: > >> On Fri, Feb 8, 2019 at 3:17 PM Christopher Barker wrote: > >> > vec_seq = Vector(seq) >> > (vec_seq * 2).name.upper() >> > # ... bunch more stuff >> > seq = vec_seq.unwrap() >> >> what type would .unwrap() return? > > The idea?and the current toy implementation/alpha?has .unwrap return whatever type went into the Vector creation. Might be a tuple, list, set, deque, or it might be an iterator. It might even be some custom collection that isn't in the standard library. > > But you can also explicitly make a Vector into something else by using that constructor. Pretty much as I gave example before: > > set(Vector(a_list)) # Get a set > Vector(a_list)).unwrap() # Get a list (without needing to know type to call .unwrap()) > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcos.eliziario at gmail.com Fri Feb 8 18:40:05 2019 From: marcos.eliziario at gmail.com (Marcos Eliziario) Date: Fri, 8 Feb 2019 21:40:05 -0200 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> <20190207234200.GI1834@ando.pearwood.info> Message-ID: Just a quick idea. Wouldn't an arrow operator -> be less of an eye sore? Em sex, 8 de fev de 2019 ?s 18:16, Christopher Barker escreveu: > On Thu, Feb 7, 2019 at 4:27 PM David Mertz wrote: > > > Actually, if I wanted an operator, I think that @ is more intuitive than > extra dots. Vectorization isn't matrix multiplication, but they are sort > of in the same ballpark, so the iconography is not ruined. > > well, vectorization is kinda the *opposite* of matrix multiplication -- > matrix multiplication is treating the matrix as a whole, rther than > applying multiplication to each element. And it is certainly the opposite > in the numpy case. > > Which gives me an idea -- we could make an object that applied operators > (and methods??) to each element individually, and use the @ operator when > you wanted the method to act on the whole object instead. > > Note: I haven't thought about the details at all -- may not be practical > to use an operator for that. > > > (Vec(seq) * 2).name.upper() > > > Or: > > > vec_seq = Vector(seq) > > (vec_seq * 2).name.upper() > > # ... bunch more stuff > > seq = vec_seq.unwrap() > > what type would .unwrap() return? > > One of the strengths of the "operator" approach is that is could apply to > any (appropriately mutable) sequence and keep that sequence. I"m not sure > how much that actually matters, as I'm expecting this is a 99% list case > anyway. > > and why would .unwrap() be required at all -- as opposed to say: > > seq = list(vec_seq) > > > I'm not saying the double dots are terrible, but they don't read > *better* than wrapping (and optionally unwrapping) to me. > > nor to me. > > > Well... your maps are kinda deliberately ugly. > > That's actually pretty key -- in fact, if you wanted to apply a handful of > operations to each item in a sequence, you would probably use a single > expression (If possible) in a lambda in a map, or in a comprehension, > rather than chaining the map. > > Even if it was more complex, you could write a function, and then apply > that with a map or comprehension. > > In the numpy case, compare: > > c = sqrt(a**2 + b**2) > > to > > c = [sqrt(a**2 + b**2) for a,b in zip(a,b)] > > so still a single comprehension. But: > > 1) given the familiariy of math expressions -- the first really does read > a LOT better > 2) the first version can be better optimized (by numpy) > > So the questions becomes: > > * For other than math with numbers (which we have numpy for), are there > use cases where we'd really get that much extra clarity? > > * Could we better optimize, say, a sequence of strings enough to make it > all worth it? > > -CHB > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marcos Elizi?rio Santos mobile/whatsapp/telegram: +55(21) 9-8027-0156 skype: marcos.eliziario at gmail.com linked-in : https://www.linkedin.com/in/eliziario/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at cskk.id.au Fri Feb 8 21:10:14 2019 From: cs at cskk.id.au (Cameron Simpson) Date: Sat, 9 Feb 2019 13:10:14 +1100 Subject: [Python-ideas] Keeping discussion relevant In-Reply-To: <8AA01359-7CA7-432F-B2EE-13DA4EF8A6B9@gmail.com> References: <8AA01359-7CA7-432F-B2EE-13DA4EF8A6B9@gmail.com> Message-ID: <20190209021014.GA90256@cskk.homeip.net> On 08Feb2019 17:15, James Lu wrote: >Sometimes I see threads briefly go into topics that are unrelated to >new features in Python. For example: talking about a writer?s use of >?inhomogeneous? vs ?heterogenous? vs ?anhomogenous.? We get what the >original author meant, there is no need to fiddle with the little >details of language at this point, even if it is fun. > >These extra emails, though harmless, impose a visual, time, and navigational burden on the readers of the thread. It?s okay if the problem is little but not if it?s big. > >Two questions: >How often does off-topic discussion occur? Does it need to be find ways to reduce the amount? >How can we find ways to reduce the amount? Conversations always branch. We try, thoguh self discipline, to keep things on topic. If you're going to diverge morethan transiently there are a few decent ways to deal with it: - edit the subject, indicating the old subject, for example: "inhomogeneous vs heterogenous (was: former subject header)" so that readers can easily identify the branch and follow/ignore it - commence a new discussion (like your post) - pointedly take it offline; mostly suitable when the topic is off topic for the list and the participants are few (ideally just 2) - take it to another suitable list (and of course say so so that interested people can follow); this has its own downsides because the other list isn't necessarily one used by everyone who cares I lean to the first of these, at least initially. It is less intrusive and makes the shift evident. Cheers, Cameron Simpson From turnbull.stephen.fw at u.tsukuba.ac.jp Sat Feb 9 06:33:02 2019 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Sat, 9 Feb 2019 20:33:02 +0900 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190207050252.GC1834@ando.pearwood.info> <7016CB32-0364-4D24-9BAA-3F8D744CF0EF@gmail.com> <20190207234200.GI1834@ando.pearwood.info> Message-ID: <23646.47726.121507.24815@turnbull.sk.tsukuba.ac.jp> Christopher Barker writes: > well, vectorization is kinda the *opposite* of matrix multiplication -- > matrix multiplication is treating the matrix as a whole, When I think of treating the matrix as a whole, I think of linear algebra. Matrix multiplication is repeated application of the inner product, which is in turn a sum over vectorized multiplication. I share David's intuition about this, although it might not be the common one. Steve From pythonchb at gmail.com Sat Feb 9 11:15:10 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sat, 9 Feb 2019 08:15:10 -0800 Subject: [Python-ideas] Keeping discussion relevant In-Reply-To: <20190209021014.GA90256@cskk.homeip.net> References: <8AA01359-7CA7-432F-B2EE-13DA4EF8A6B9@gmail.com> <20190209021014.GA90256@cskk.homeip.net> Message-ID: I'm trying to not be snarky here, but frankly, these "meta-conversations" about how and what we should discuss on the list are more distracting to me than the occasional OT wanderings ... -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From klahnakoski at mozilla.com Sun Feb 10 13:05:42 2019 From: klahnakoski at mozilla.com (Kyle Lahnakoski) Date: Sun, 10 Feb 2019 13:05:42 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190202231101.GP1834@ando.pearwood.info> References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202231101.GP1834@ando.pearwood.info> Message-ID: On 2019-02-02 18:11, Steven D'Aprano wrote: > We can improve that comprehension a tiny bit by splitting it into > multiple steps: > > temp1 = [d+e for d, e in zip(vector, sequence)] > temp2 = [process(c) for x in temp1] > result = [a*b for a, b in zip(temp2, items)] > > but none of these are as elegant or readable as the vectorized syntax > > result = process.(vector .+ sequence) .* items The following reads a little better: | result = [ |? ?? process(v+s)*i |???? for v, s, i in zip(vector, sequence, items) | ] Vector operations will promote the use of data formats that work well with vector operations. So, I would expect data to appear like rows in a table, rather than in the columnar form shown above. Even if columnar form must be dealt with, we can extend our Vector class (or whatever abstraction you are using to enter vector space) to naturally zip() columns. | Vector(zip(vector, sequence, items)) | ? ? .map(lambda v, s, i: process(v+s)*i) ??? If we let Vector represent a list of tuples instead of a list of values, we can make construction simpler: | Vector(vector, sequence, items) | ? ? .map(lambda v, s, i: process(v+s)*i) ??? If we have zip() to extend the tuples in the Vector, then we can be verbose to demonstrate how to use columnar data: | Vector(vector) |???? .zip(sequence) |???? .map(operator.add) |???? .map(process) |???? .zip(items) |???? .map(operator.mul) This looks verbose, but it is not too far from the vectorized syntax: the Vector() brings us to vector mode, and the two zip()s convert from columnar form. This verbose form may be *better* than the vectorized syntax because the operations are in order, rather than the mixing infix and functional forms seen in the vectorized syntax form. I suggest this discussion include vector operations on (frozen) dicts/objects and (frozen) lists/tuples.? Then we can have an interesting discussion about the meaning of group_by, join, and window functions, plus other operations we find in database query languages. I am interested in vector operations.? I have situations where I want to perform some conceptually simple operations on a series of not-defined-by-me objects to make a series of conclusions.? The calculations can be done succinctly in SQL, but Python makes them difficult. Right now, my solution is to describe the transformations in JSON, and have an interpreter do the processing: https://github.com/klahnakoski/SpotManager/blob/65f2c5743f3a9cfd1363cafec258c0a663e194c3/spot/spot_manager.py#L611 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jpgkifbeadmcaigm.png Type: image/png Size: 62836 bytes Desc: not available URL: From pythonchb at gmail.com Sun Feb 10 16:51:58 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sun, 10 Feb 2019 13:51:58 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190131232307.GR1834@ando.pearwood.info> <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202231101.GP1834@ando.pearwood.info> Message-ID: On Sun, Feb 10, 2019 at 10:06 AM Kyle Lahnakoski wrote: > but none of these are as elegant or readable as the vectorized syntax > > result = process.(vector .+ sequence) .* items > > I've a bit lost track of who is proposing what, but this looks like an extra set of operators: ".*", ".+" etc. for vectorized operations. So I want to point out that is was proposed way back when for numpy: MATLAB for instance, has a the usual operators: *, +, etc meaning "matrix math", and then another set of "itemwise" operators with a "dot form: .*, .+ . - for "itemwise" math. numpy, on the other other had uses the regular operators for itemwise operations (what we're calling vectorized here), and Python lacked an extra set of operators that could be used for matrix math. Adding another full set (.*, .+, etc) was discussed A LOT and the Python community did not want that. Then someone had the brilliant observation that matrix multiplication was teh only one that was really useful and presto! the @ operator was born. Anyway -- just suggesting that a full set of "vectorized" operators will liley see a lot of resistance. And for my part, having mean the opposite of what it does for numpy would be unfortunate as well. > I am interested in vector operations. I have situations where I want to perform some conceptually simple operations on a series of not-defined-by-me objects to make a series of conclusions. The calculations can be done succinctly in SQL, but Python makes them difficult. Bringing real world examples of this would be a good idea for this discussion I'm inclined to think that something like pandas (maybe more generally SQL -like that the number crunching focus of Pandas) might be better than new syntax for the language -- but only real examples will tell. I don't work with data like that much, but I"m pretty sure I've seen Python packages that to attempt to address these use cases. (that being querying and processing tabular data) -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jpgkifbeadmcaigm.png Type: image/png Size: 62836 bytes Desc: not available URL: From steve at pearwood.info Sun Feb 10 18:30:25 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Mon, 11 Feb 2019 10:30:25 +1100 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202231101.GP1834@ando.pearwood.info> Message-ID: <20190210233024.GP1834@ando.pearwood.info> On Sun, Feb 10, 2019 at 01:05:42PM -0500, Kyle Lahnakoski wrote: > I am interested in vector operations.? I have situations where I want to > perform some conceptually simple operations on a series of > not-defined-by-me objects to make a series of conclusions.? The > calculations can be done succinctly in SQL, but Python makes them > difficult. Can you post a simplified example of how you would do it in SQL, compared to what you would have to do in standard Python? -- Steven From klahnakoski at mozilla.com Mon Feb 11 00:22:48 2019 From: klahnakoski at mozilla.com (Kyle Lahnakoski) Date: Mon, 11 Feb 2019 00:22:48 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <20190210233024.GP1834@ando.pearwood.info> References: <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202231101.GP1834@ando.pearwood.info> <20190210233024.GP1834@ando.pearwood.info> Message-ID: <8e7489e2-21ee-a92c-9d3e-a7061dc74a2b@mozilla.com> On 2019-02-10 18:30, Steven D'Aprano wrote: > > Can you post a simplified example of how you would do it in SQL, > compared to what you would have to do in standard Python? Can I do the same in standard Python? If I did, then I would use Pandas: it has groupby, and some primitive joining, and window functions may come naturally because of its imperative nature, but I have not tried it.? If I can not use Pandas, then I would write the groupby and window functions and call them in sequence. This is similar to what you see in my code now: a number of properties who's values get dispatched to Python functions.? My code is more complicated only because those structures can be dispatched to translators for databases too. I am certain there are many variations of groupby out in the wild, and it would be nice to have the concept standardized when/if Python has vector operations. Join would be nice to have too, but I do not use it much; dictionary lookup seems to fill that need.? Window functions (which are like mini queries) are powerful, but like Pandas, may end up end up being free because Python is imperative. My code I pointed to has two parts. Here is the first part in SQL (well, an approximation of SQL since I did not test this, and now I am rusty).? A detailed description is below |?? WITH time_range AS ( |?????? SELECT |?????????? num |?????? FROM |?????????? all_integers |?????? WHERE |?????????? num % 60 =0 AND |?????????? num >= floor(<>/60/60)*60*60-<> AND |?????????? num < floor(<>/60/60) + 60*60 |?? ) |?? SELECT? |?????? availability_zone, |?????? instance_type, |?????? time_range.num AS time |?????? MAX(price) as PRICE, |?????? COUNT(1) AS `COUNT`, |?????? LAST(current_price) OVER ( |?????????? PARTITION BY |?????????????? availability_zone, |?????????????? instance_type |?????????? ORDER BY |?????????????? timestamp |?????? ) AS current_price |?? FROM |?????? ( |?????????? SELECT |?????????????? *, |?????????????? COALESCE(LAG(timestampvalue, 1), <>) OVER ( |?????????????????? PARTITION BY |?????????????????????? availability_zone, |?????????????????????? instance_type |?????????????????? ORDER BY |?????????????????????? timestamp |?????????????? ) AS expire, |?????????????? timestamp-<> AS effective |?????????? FROM |?????????????? prices |?????? ) temp |?? RIGHT JOIN |?????? time_range ON time_range.num BETWEEN temp.effective AND temp.expire |?? GROUP BY |?????? availability_zone, |?????? instance_type, |?????? time_range.num AS time |?? WHERE |?????? expire > floor(<>/60/60)*60*60 - <> Now, for the same, with description: This WITH clause is not real SQL; it is meant to stand in for a temporary table that contains all hours of the time range I am interested. Definitely easier to do in Python. All time is assumed to be in seconds since epoch. |?? WITH time_range AS ( |?????? SELECT |?????????? num |?????? FROM |?????????? all_integers |?????? WHERE |?????????? num % 60 =0 AND |?????????? num >= floor(<>/60/60)*60*60-<> AND |?????????? num < floor(<>/60/60) + 60*60 |?? ) We will select the three dimensions we are interested in (see GROUP BY below), along with the MAX price we have seen in the given hour, and the current_price for any (availability_zone, instance_type) pair. |?? SELECT? |?????? availability_zone, |?????? instance_type, |?????? time_range.num AS time |?????? MAX(price) as PRICE, |?????? COUNT(1) AS `COUNT`, |?????? LAST(current_price) OVER ( |?????????? PARTITION BY |?????????????? availability_zone, |?????????????? instance_type |?????????? ORDER BY |?????????????? timestamp |?????? ) AS current_price |?? FROM The prices coming from Amazon only have a timestamp for when that price is effective; so this sub-query adds an `effective` start time, and an `expire` time so the rest of the query need only deal with ranges. The? timestamp-<> is putting the start time back further into the past so the past can "see" future pricing.? |?????? ( |?????????? SELECT |?????????????? *, |?????????????? COALESCE(LAG(timestamp, 1), <>) OVER ( |?????????????????? PARTITION BY |?????????????????????? availability_zone, |?????????????????????? instance_type |?????????????????? ORDER BY |?????????????????????? timestamp |?????????????? ) AS expire, |?????????????? timestamp-<> AS effective |?????????? FROM |?????????????? prices |?????? ) temp This is the point where we use the time_range from above and find every hour a price is effective.? This could have been a sub-query, but I am rusty at SQL |?? RIGHT JOIN |?????? time_range ON time_range.num BETWEEN temp.effective AND temp.expire These are the three dimensions we are interested in |?? GROUP BY |?????? availability_zone, |?????? instance_type, |?????? time_range.num AS time and we are only interested in calculating back to a certain point |?? WHERE |?????? expire > floor(<>/60/60)*60*60 - <> From pythonchb at gmail.com Mon Feb 11 10:43:12 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Mon, 11 Feb 2019 07:43:12 -0800 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: <8e7489e2-21ee-a92c-9d3e-a7061dc74a2b@mozilla.com> References: <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202231101.GP1834@ando.pearwood.info> <20190210233024.GP1834@ando.pearwood.info> <8e7489e2-21ee-a92c-9d3e-a7061dc74a2b@mozilla.com> Message-ID: Do take a look in the fairly recent archives of this list for a big discussion of groupby -- it kind of petered out but there were a couple options on the table. -CHB On Sun, Feb 10, 2019 at 9:23 PM Kyle Lahnakoski wrote: > > On 2019-02-10 18:30, Steven D'Aprano wrote: > > > > Can you post a simplified example of how you would do it in SQL, > > compared to what you would have to do in standard Python? > > Can I do the same in standard Python? If I did, then I would use Pandas: > it has groupby, and some primitive joining, and window functions may > come naturally because of its imperative nature, but I have not tried > it. If I can not use Pandas, then I would write the groupby and window > functions and call them in sequence. This is similar to what you see in > my code now: a number of properties who's values get dispatched to > Python functions. My code is more complicated only because those > structures can be dispatched to translators for databases too. > > I am certain there are many variations of groupby out in the wild, and > it would be nice to have the concept standardized when/if Python has > vector operations. Join would be nice to have too, but I do not use it > much; dictionary lookup seems to fill that need. Window functions > (which are like mini queries) are powerful, but like Pandas, may end up > end up being free because Python is imperative. > > My code I pointed to has two parts. Here is the first part in SQL (well, > an approximation of SQL since I did not test this, and now I am rusty). > A detailed description is below > > | WITH time_range AS ( > | SELECT > | num > | FROM > | all_integers > | WHERE > | num % 60 =0 AND > | num >= floor(<>/60/60)*60*60-<> AND > | num < floor(<>/60/60) + 60*60 > | ) > | SELECT > | availability_zone, > | instance_type, > | time_range.num AS time > | MAX(price) as PRICE, > | COUNT(1) AS `COUNT`, > | LAST(current_price) OVER ( > | PARTITION BY > | availability_zone, > | instance_type > | ORDER BY > | timestamp > | ) AS current_price > | FROM > | ( > | SELECT > | *, > | COALESCE(LAG(timestampvalue, 1), <>) OVER ( > | PARTITION BY > | availability_zone, > | instance_type > | ORDER BY > | timestamp > | ) AS expire, > | timestamp-<> AS effective > | FROM > | prices > | ) temp > | RIGHT JOIN > | time_range ON time_range.num BETWEEN temp.effective AND temp.expire > | GROUP BY > | availability_zone, > | instance_type, > | time_range.num AS time > | WHERE > | expire > floor(<>/60/60)*60*60 - <> > > > Now, for the same, with description: > > This WITH clause is not real SQL; it is meant to stand in for a > temporary table that contains all hours of the time range I am > interested. Definitely easier to do in Python. All time is assumed to be > in seconds since epoch. > > | WITH time_range AS ( > | SELECT > | num > | FROM > | all_integers > | WHERE > | num % 60 =0 AND > | num >= floor(<>/60/60)*60*60-<> AND > | num < floor(<>/60/60) + 60*60 > | ) > > We will select the three dimensions we are interested in (see GROUP BY > below), along with the MAX price we have seen in the given hour, and the > current_price for any (availability_zone, instance_type) pair. > > | SELECT > | availability_zone, > | instance_type, > | time_range.num AS time > | MAX(price) as PRICE, > | COUNT(1) AS `COUNT`, > | LAST(current_price) OVER ( > | PARTITION BY > | availability_zone, > | instance_type > | ORDER BY > | timestamp > | ) AS current_price > | FROM > > The prices coming from Amazon only have a timestamp for when that price > is effective; so this sub-query adds an `effective` start time, and an > `expire` time so the rest of the query need only deal with ranges. The > timestamp-<> is putting the start time back further > into the past so the past can "see" future pricing. > > | ( > | SELECT > | *, > | COALESCE(LAG(timestamp, 1), <>) OVER ( > | PARTITION BY > | availability_zone, > | instance_type > | ORDER BY > | timestamp > | ) AS expire, > | timestamp-<> AS effective > | FROM > | prices > | ) temp > > This is the point where we use the time_range from above and find every > hour a price is effective. This could have been a sub-query, but I am > rusty at SQL > > | RIGHT JOIN > | time_range ON time_range.num BETWEEN temp.effective AND temp.expire > > These are the three dimensions we are interested in > > | GROUP BY > | availability_zone, > | instance_type, > | time_range.num AS time > > and we are only interested in calculating back to a certain point > > | WHERE > | expire > floor(<>/60/60)*60*60 - <> > > > > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From klahnakoski at mozilla.com Mon Feb 11 11:34:17 2019 From: klahnakoski at mozilla.com (Kyle Lahnakoski) Date: Mon, 11 Feb 2019 11:34:17 -0500 Subject: [Python-ideas] Vectorization [was Re: Add list.join() please] In-Reply-To: References: <20190202043254.GG1834@ando.pearwood.info> <9613f674-65fc-7d41-c0ea-f3c0cf056ce3@mrabarnett.plus.com> <00adb661-92f3-4d17-e801-7e50ea61032c@mrabarnett.plus.com> <92cc2148-240c-4790-c133-d9f6f0d55210@farowl.co.uk> <20190202231101.GP1834@ando.pearwood.info> <20190210233024.GP1834@ando.pearwood.info> <8e7489e2-21ee-a92c-9d3e-a7061dc74a2b@mozilla.com> Message-ID: <9f3fbf56-c7f6-a2f9-9f12-d7c9702de2ac@mozilla.com> CHB, Thank you! I had forgotten that discussion at the beginning of July [1].? Googling the list [2] also shows mention of PythonQL [3], which may point to use cases that can guide a Vectorization idea. [1] groupby discussion - https://mail.python.org/pipermail/python-ideas/2018-July/051786.html [2] google search - https://www.google.ca/search?q=group+by+site%3Ahttps%3A%2F%2Fmail.python.org%2Fpipermail%2Fpython-ideas%2F&oq=group+by+site%3Ahttps%3A%2F%2Fmail.python.org%2Fpipermail%2Fpython-ideas%2F [3] PythonQL - https://github.com/pythonql/pythonql On 2019-02-11 10:43, Christopher Barker wrote: > Do take a look in the fairly recent archives of this list for a big > discussion of groupby -- it kind of petered out but there were a > couple options on the table. > > -CHB > From thebigcheese65535 at gmail.com Thu Feb 14 04:47:16 2019 From: thebigcheese65535 at gmail.com (The Big Cheese) Date: Thu, 14 Feb 2019 09:47:16 +0000 Subject: [Python-ideas] __first__ method Message-ID: I have an idea for a new special method in a class called __first__(). The main purpose of it would be to setup somethings a class needs to run before it is first initiated, probably only really in modules because in your code you could simply put this setup stuff before the class however if you are calling something like 'from foo import Bar', where Bar is a class and Bar needs some specific imports you would need something to run the first time Bar is initiated. I have two possible ideas for how this could be done. To look at how this is going to work I will make an example class which would be in the class foo: class Bar(object): def __first__(): import math def __init__(self, n): self.a = math.log(2, n) The first possible way is that if you just call Bar (without brackets or any attributes) this is when it will run __first__ so you can just do this after you run 'from foo import Bar'. However I don't particularly like this idea because you could just create a staticmethod setup or something instead of __first__ and then rather than running Bar you would just run Bar.setup(), not much harder. Personally I prefer my second idea. This is that when you first run Bar.__new__() it will check if it has a __first__() and if so it will run __first__ and then it will run the normal __new__. However, if you then create another instance, so run __new__ again, it will not run __first__ again so it is still an efficient place to run imports or setup of things. As an example of where this could be useful, I made a module 'temperature' to help me neatly read one-wire temperature sensors with a raspberry pi. This included a class Sensor which you gave the code of the sensor and then when you called temp of that instance it will return what temperature that sensor is reading. I would like in my other code to be able to run 'from temperature import Sensor' because that would then mean I could just call Sensor('28-000648372f') to create a sensor however at the start of this module it imports os and glob and it also runs some setup for how it reads the sensors and has such I have to just do 'import temperature' and then every time I create a sensor I have to call temperature.Sensor which isn't as nice. I was wondering what you thought of this idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Thu Feb 14 05:03:10 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 14 Feb 2019 23:03:10 +1300 Subject: [Python-ideas] __first__ method In-Reply-To: References: Message-ID: <5C653CDE.1020801@canterbury.ac.nz> The Big Cheese wrote: > however at the start of this module it imports os and glob and it also > runs some setup for how it reads the sensors and has such I have to just > do 'import temperature' and then every time I create a sensor I have to > call temperature.Sensor which isn't as nice. I think you may be mistaken about how module importing works. Doing 'from temperature import Sensor' still runs all the top-level code in the temperature module, just the same as 'import temperature' does. So, the feature you're requesting is not necessary. All you have to do is write your setup code as top-level statements in the module where the class is defined. -- Greg From pythonchb at gmail.com Thu Feb 14 11:32:47 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Thu, 14 Feb 2019 08:32:47 -0800 Subject: [Python-ideas] __first__ method In-Reply-To: References: Message-ID: I forstthpughthgegoal here was to avoid imports that may not be needed if the class isn?t actually used. If that?s the case, then it?s better to simply put classes with heavyweight imports in their own module. And: class Bar(object): > def __first__(): > import math > def __init__(self, n): > self.a = math.log(2, n) > This would bring ?math? into the __first__ function?s local namespace, and it would not be accessible in other methods anyway. You could put that import line in __init__, or, if needed in other methods, in __init__: Import math self.math = math Then it wouldn?t get imported until the first instance was created. But this is generally not considered good style. I have, occasionally, imported heavy weight modules in optional, rarely used, methods so that they aren?t imported (or even need to be there) if they aren?t needed. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane at wirtel.be Thu Feb 14 16:21:08 2019 From: stephane at wirtel.be (Stephane Wirtel) Date: Thu, 14 Feb 2019 22:21:08 +0100 Subject: [Python-ideas] __first__ method In-Reply-To: References: Message-ID: <20190214212108.GA8646@xps> -1 for the idea, sorry -- St?phane Wirtel - https://wirtel.be - @matrixise From mistersheik at gmail.com Sun Feb 17 05:28:49 2019 From: mistersheik at gmail.com (Neil Girdhar) Date: Sun, 17 Feb 2019 02:28:49 -0800 (PST) Subject: [Python-ideas] Please consider adding an overrideable flag to abstractmethod Message-ID: Marking a method M declared in C with abstractmethod indicates that M needs to be *implemented* in any subclass D of C for D to be instantiated. We usually think of overriding a method N to mean replacing one implementation in some class E with another in some subclass of E, F. Often, the subclass implementation calls super to add behavior rather than replace it. I think that this concept of *implementing* is different than *overriding*. However, abstract classes can have reasonable definition, and should sometimes be overridden in the sense that subclasses should call super. For example, when inheriting from AbstractContextManager, you need to *override* the abstractmethod (!) __exit__, and if you want your class to work polymorphically, you should call super. This is extremely weird. Understandably, the pylint people are confused by it (https://github.com/PyCQA/pylint/issues/1594) and raise bad warnings. It also makes it impossible for me to raise warnings in my ipromise (https://github.com/NeilGirdhar/ipromise) project. See, for example, https://github.com/NeilGirdhar/ipromise/blob/master/ipromise/test/test_overrides.py classes Y and W, which ought to raise, but that would raise on reasonable code. My suggestion is to add a rarely used flag to abstractmethod: class AbstractContextManager: @abstractmethod(overrideable=True) def __exit__(self, exc_type, exc_value, traceback): pass This would set a flag on the method like __abstractmethod_overrideable__, which could be checked by ipromise's @overrides decorator, pylint's call check, and anyone else that wants to know that a method should be overridden. Best, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mistersheik at gmail.com Sun Feb 17 05:32:28 2019 From: mistersheik at gmail.com (Neil Girdhar) Date: Sun, 17 Feb 2019 02:32:28 -0800 (PST) Subject: [Python-ideas] Please consider adding an overrideable flag to abstractmethod In-Reply-To: References: Message-ID: <213b9e35-5f16-4ca5-b85d-ea3ff65d8af4@googlegroups.com> Alternatively, the need for an overriding implementation to call super could be marked by a different decorator. This would allow linters to check that subclasses call super when they should, which is a very useful check in my opinion. Such a decorator could be called "@overrideable", and could be exposed in abc. When used in combination with @abstractmethod, it could have the above behavior. On Sunday, February 17, 2019 at 5:28:49 AM UTC-5, Neil Girdhar wrote: > > Marking a method M declared in C with abstractmethod indicates that M > needs to be *implemented* in any subclass D of C for D to be instantiated. > > We usually think of overriding a method N to mean replacing one > implementation in some class E with another in some subclass of E, F. > Often, the subclass implementation calls super to add behavior rather than > replace it. > > I think that this concept of *implementing* is different than *overriding*. > > However, abstract classes can have reasonable definition, and should > sometimes be overridden in the sense that subclasses should call super. > For example, when inheriting from AbstractContextManager, you need to > *override* the abstractmethod (!) __exit__, and if you want your class to > work polymorphically, you should call super. > > This is extremely weird. Understandably, the pylint people are confused > by it (https://github.com/PyCQA/pylint/issues/1594) and raise bad > warnings. > > It also makes it impossible for me to raise warnings in my ipromise ( > https://github.com/NeilGirdhar/ipromise) project. See, for example, > https://github.com/NeilGirdhar/ipromise/blob/master/ipromise/test/test_overrides.py > classes Y and W, which ought to raise, but that would raise on reasonable > code. > > My suggestion is to add a rarely used flag to abstractmethod: > > class AbstractContextManager: > @abstractmethod(overrideable=True) > def __exit__(self, exc_type, exc_value, traceback): > pass > > This would set a flag on the method like __abstractmethod_overrideable__, > which could be checked by ipromise's @overrides decorator, pylint's call > check, and anyone else that wants to know that a method should be > overridden. > > Best, > > Neil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Sun Feb 17 11:34:51 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Sun, 17 Feb 2019 08:34:51 -0800 Subject: [Python-ideas] Please consider adding an overrideable flag to abstractmethod In-Reply-To: References: <213b9e35-5f16-4ca5-b85d-ea3ff65d8af4@googlegroups.com> Message-ID: reposting -- things go to heck when posts are forwarded through google groups :-( -CHB On Sun, Feb 17, 2019 at 8:32 AM Christopher Barker wrote: > On Sun, Feb 17, 2019 at 2:32 AM Neil Girdhar > wrote: > >> Alternatively, the need for an overriding implementation to call super >> could be marked by a different decorator. >> > > Looking back on the old "Super considered [Harmful | Super]" discussions, > it was clear that the fact that a class hierarchy uses super() is part if > its API, and: > > and every occurrence of the method needs to use super() > > So +1 on having an explicit way to specify that super should be used in > subclasses, rather than having to look in documentation or the source code > to figure that out. > > -CHB > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.input at gmail.com Mon Feb 18 11:52:20 2019 From: carl.input at gmail.com (Carl Smith) Date: Mon, 18 Feb 2019 16:52:20 +0000 Subject: [Python-ideas] Consistency in naming [was Re: ...ALL CAPS] (off-list) In-Reply-To: References: <117d8126-5db2-2641-2f87-69562dd69320@trueblade.com> <20190201215752.GZ1834@ando.pearwood.info> <04ADCDC5-9384-4725-AE3E-5ED806B0D3E7@killingar.net> <20190201223409.GB1834@ando.pearwood.info> <8152F93A-7877-4ABB-9F38-D3563B3952A1@killingar.net> <20190202084124.GJ1834@ando.pearwood.info> <588a27ff-538b-1fe2-44cf-3c07e575baf7@nedbatchelder.com> <68272EFC-EBA5-45C8-A675-E1AC8BF5CFF8@gmail.com> Message-ID: I shouldn't let it bother me, but that "Sent from my iPhone" cruft really gets under my skin. -- Carl Smith carl.input at gmail.com On Mon, 4 Feb 2019 at 11:17, Paul Moore wrote: > On Mon, 4 Feb 2019 at 05:36, Christopher Barker > wrote: > > > > This is getting pretty off toipic, but I want to point out hat as a > rule, Python has been critisised more for having too MUCH cnage than too > little over the last few years: > [...] > > Finally, what the heck is wrong with datetime.now ? > > Surely what's wrong is the fact that it adds another item to the list > of changes that people will complain is "too much"? The conservatism > in Python's development is not a result of the core devs being change > averse, or because of a policy of blocking change. Rather it's because > *the user community* reacts so strongly when we change things, so that > we feel that stability is what our users want, and try to achieve that > while still balancing the need for the language to grow and develop. > > In a list like this, which represents only a tiny fraction of Python's > user community, it's easy to misjudge the appetite Python's users have > for change, because this is a self-selecting group of people who are > interested in change. That's why the pushback on *any* proposal made > here is to ask what benefits it gives, and why in the absence of good > arguments for a change, "the status quo wins". > > Paul > > PS Personally, I'd love to add a lot of the ideas discussed in this > list (although I'm "meh" about datetime.now, it's at best a minor > annoyance). But with my "python developer" hat on I have to look > beyond that and try to help proposers develop a good case for their > suggestions (if indeed they do have sufficient merit). Just saying > "yay, that sounds cool" doesn't do that, even if it's my personal > instinct. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Mon Feb 18 19:16:23 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 19 Feb 2019 11:16:23 +1100 Subject: [Python-ideas] Discuss: what should statistics.mode do? Message-ID: <20190219001622.GC4465@ando.pearwood.info> See https://bugs.python.org/issue35892 The issue here is that statistics.mode, as initially designed, raises an exception for the case of multiple equal most-frequent data points. This is true to the way mode is taught in schools, but it may not be the most useful behaviour. Raymond has suggested: - keep the status quo; - change mode() to return "the first tie" instead of raising an exception (with or without a deprecation warning for one release); - add a flag to specify the behaviour. I'm especially interested in opinions from those who use the function. What would be useful for you? How do you use it? interactively or in scripts? (When I designed this, I mostly imagined that mode() would be used interactively, using the interpreter as a calculator.) Would changing the behaviour break your code? Note that this question is seperate from that of whether or not there should be a multimode function. -- Steven From simon.bordeyne at gmail.com Mon Feb 18 23:37:29 2019 From: simon.bordeyne at gmail.com (Simon) Date: Tue, 19 Feb 2019 05:37:29 +0100 Subject: [Python-ideas] PEP 8 update on line length Message-ID: Hello, I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated. I understand the need for it, back when monitors were small, and everyone coded on terminals, but nowadays, I feel like that guideline is more of a hinderance, and that it promotes poor code. Indeed, people abiding by this rule tend to choose shorter variable names, reduce the amount of indentation, and other tricks to just keep the character count under 80. I think a 100 or even 120 suggested characters per line count is much more realistic by today's standards. It still allow for the code to be completely displayed, even on just half of a screen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Mon Feb 18 23:48:37 2019 From: mertz at gnosis.cx (David Mertz) Date: Mon, 18 Feb 2019 23:48:37 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: You either have much better eyes to read tiny fonts than I do, or maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). But that's not even the real issue. If the characters were in giant letters on billboards, I still would never want more than 80 of them on a line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience with writing show that cognitive burden goes up exponentially, not linearly, as lines get to be more than about 60 characters. This is why it's not just code on screen. Magazines, books, wall signs, billboards, and every other written form, insists on similar limits on line length. In printed matter this often means using multiple columns to avoid overly long lines. The issue isn't resolution or size, it's that the human brain simply doesn't process long lines of text will. On Mon, Feb 18, 2019, 11:38 PM Simon Hello, > > I'd like to propose an update to PEP8. Indeed, the 80 characters per line > guideline is, I feel, outdated. > > I understand the need for it, back when monitors were small, and everyone > coded on terminals, but nowadays, I feel like that guideline is more of a > hinderance, and that it promotes poor code. > > Indeed, people abiding by this rule tend to choose shorter variable names, > reduce the amount of indentation, and other tricks to just keep the > character count under 80. I think a 100 or even 120 suggested characters > per line count is much more realistic by today's standards. It still allow > for the code to be completely displayed, even on just half of a screen. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Tue Feb 19 00:09:18 2019 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 19 Feb 2019 00:09:18 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: On 2/18/2019 11:37 PM, Simon wrote: > Hello, > > I'd like to propose an update to PEP8. Indeed, the 80 characters per > line guideline is, I feel, outdated. Strictly speaking, PEP8 applies only to CPython stdlib code. Please read the introduction. Adapt it as you will for your code. > I understand the need for it, back when monitors were small, and > everyone coded on terminals, but nowadays, I feel like that guideline is > more of a hinderance, and that it promotes poor code. The majority of core developers, to whom PEP 8 applies, seem to disagree. > Indeed, people abiding by this rule tend to choose shorter variable > names, reduce the amount of indentation, and other tricks to just keep > the character count under 80. I think a 100 or even 120 suggested > characters per line count is much more realistic by today's standards. > It still allow for the code to be completely displayed, even on just > half of a screen. Do you every print on paper? In tiny type? Or sideways? Anyway, 3 80-column windows side-by-side is really nice. For instance, shell, code file, test file. -- Terry Jan Reedy From gadgetsteve at live.co.uk Tue Feb 19 00:47:49 2019 From: gadgetsteve at live.co.uk (Steve Barnes) Date: Tue, 19 Feb 2019 05:47:49 +0000 Subject: [Python-ideas] Discuss: what should statistics.mode do? In-Reply-To: <20190219001622.GC4465@ando.pearwood.info> References: <20190219001622.GC4465@ando.pearwood.info> Message-ID: -----Original Message----- From: Python-ideas On Behalf Of Steven D'Aprano Sent: 19 February 2019 00:16 To: python-ideas at python.org Subject: [Python-ideas] Discuss: what should statistics.mode do? See https://bugs.python.org/issue35892 The issue here is that statistics.mode, as initially designed, raises an exception for the case of multiple equal most-frequent data points. This is true to the way mode is taught in schools, but it may not be the most useful behaviour. Raymond has suggested: - keep the status quo; - change mode() to return "the first tie" instead of raising an exception (with or without a deprecation warning for one release); - add a flag to specify the behaviour. I'm especially interested in opinions from those who use the function. What would be useful for you? How do you use it? interactively or in scripts? (When I designed this, I mostly imagined that mode() would be used interactively, using the interpreter as a calculator.) Would changing the behaviour break your code? Note that this question is seperate from that of whether or not there should be a multimode function. [Steve Barnes] Can I suggest that one option other would be to modify the current exception, (e.g. "StatisticsError: no unique mode; found 2 equally common values"), to include the count and the values either as an additional property of the exception, or as a part of the text (probably with some truncation). Being told that there are n equally common values, either working interactively or in a script, is of limited value but being told what they are would be much more valuable. Currently once I know that there are multiple "mode" values I would have to switch to collections Counter for most_common or some such and recalculate - (keeping in mind that I might be processing millions of values). Since mode only really makes sense for discrete values such as integers it is important information as a) the count might be 1 i.e. all the values are unique, b) if there are 2 or 3 modes and they are adjacent the mid-point can be used as a sensible approximation or c) if there are 2 or more distinct clusters it helps to visualise this without having a plot. I also think that this would be the change with minimal disruption of the status quo as all existing code will still get the exception but with (optionally) more useful information. Steve Barnes From boxed at killingar.net Tue Feb 19 01:11:17 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Feb 2019 07:11:17 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: <4AD13184-142A-4C10-A0DD-92D9199A585F@killingar.net> > On 19 Feb 2019, at 05:48, David Mertz wrote: > > You either have much better eyes to read tiny fonts than I do, or maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). > > But that's not even the real issue. If the characters were in giant letters on billboards, I still would never want more than 80 of them on a line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience with writing show that cognitive burden goes up exponentially, not linearly, as lines get to be more than about 60 characters. If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders From gadgetsteve at live.co.uk Tue Feb 19 01:20:20 2019 From: gadgetsteve at live.co.uk (Steve Barnes) Date: Tue, 19 Feb 2019 06:20:20 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <4AD13184-142A-4C10-A0DD-92D9199A585F@killingar.net> References: <4AD13184-142A-4C10-A0DD-92D9199A585F@killingar.net> Message-ID: From: Python-ideas On Behalf Of Anders Hovm?ller Sent: 19 February 2019 06:11 To: David Mertz Cc: Simon ; python-ideas Subject: Re: [Python-ideas] PEP 8 update on line length > On 19 Feb 2019, at 05:48, David Mertz wrote: > > You either have much better eyes to read tiny fonts than I do, or maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). > > But that's not even the real issue. If the characters were in giant letters on billboards, I still would never want more than 80 of them on a line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience with writing show that cognitive burden goes up exponentially, not linearly, as lines get to be more than about 60 characters. If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders [Steve Barnes] If you are getting to 40 spaces of indent, (for _most_ people that is 10 scope changes, e.g. fn then 9 levels of if), then you are already facing a major cognitive burden and should probably be refactoring. From mertz at gnosis.cx Tue Feb 19 01:28:36 2019 From: mertz at gnosis.cx (David Mertz) Date: Tue, 19 Feb 2019 01:28:36 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <4AD13184-142A-4C10-A0DD-92D9199A585F@killingar.net> References: <4AD13184-142A-4C10-A0DD-92D9199A585F@killingar.net> Message-ID: 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on. But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example. Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif. On Tue, Feb 19, 2019, 1:11 AM Anders Hovm?ller > > > On 19 Feb 2019, at 05:48, David Mertz wrote: > > > > You either have much better eyes to read tiny fonts than I do, or maybe > a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop > bag). > > > > But that's not even the real issue. If the characters were in giant > letters on billboards, I still would never want more than 80 of them on a > line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia > of experience with writing show that cognitive burden goes up > exponentially, not linearly, as lines get to be more than about 60 > characters. > > If that is the issue then we should be talking about non-space characters, > not a 68 column limit right? No way does 40 spaces due to indent count > towards the cognitive burden :) > > Also, if the cognitive burden is the issue then we should talk about short > forms for keyword arguments again. The way the 68 column limit works in > practice is that people avoid keyword arguments because of line length, > plus the issues already mentioned. > > / Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmueller at python-academy.de Tue Feb 19 02:29:03 2019 From: mmueller at python-academy.de (=?UTF-8?Q?Mike_M=c3=bcller?=) Date: Tue, 19 Feb 2019 08:29:03 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: Am 19.02.19 um 05:37 schrieb Simon: > Hello, > > I'd like to propose an update to PEP8. Indeed, the 80 characters per line > guideline is, I feel, outdated. > > I understand the need for it, back when monitors were small, and everyone > coded on terminals, but nowadays, I feel like that guideline is more of a > hinderance, and that it promotes poor code. > > Indeed, people abiding by this rule tend to choose shorter variable names, > reduce the amount of indentation, and other tricks to just keep the > character count under 80. I think a 100 or even 120 suggested characters per > line count is much more realistic by today's standards. It still allow for > the code to be completely displayed, even on just half of a screen. If I read PEP8 correctly, the limit is effectively extended to 100 (well, 99) characters already: Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. https://www.python.org/dev/peps/pep-0008/ Mike From cs at cskk.id.au Tue Feb 19 04:15:48 2019 From: cs at cskk.id.au (Cameron Simpson) Date: Tue, 19 Feb 2019 20:15:48 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: <20190219091548.GA10271@cskk.homeip.net> On 19Feb2019 00:09, Terry Reedy wrote: >On 2/18/2019 11:37 PM, Simon wrote: >>I'd like to propose an update to PEP8. Indeed, the 80 characters per >>line guideline is, I feel, outdated. >>I understand the need for it, back when monitors were small, and >>everyone coded on terminals, but nowadays, I feel like that guideline >>is more of a hinderance, and that it promotes poor code. > >The majority of core developers, to whom PEP 8 applies, seem to disagree. I'm not a core developer and I also disagree. >>Indeed, people abiding by this rule tend to choose shorter variable >>names, reduce the amount of indentation, and other tricks to just >>keep the character count under 80. I think a 100 or even 120 >>suggested characters per line count is much more realistic by >>today's standards. It still allow for the code to be completely >>displayed, even on just half of a screen. > >Do you every print on paper? In tiny type? Or sideways? > >Anyway, 3 80-column windows side-by-side is really nice. For instance, >shell, code file, test file. I like 4 80 column windows. 2 for the editing and either 2 shells or a single wide shell. And 80 columns doesn't really influence my variable name sizes. The longer the line, the harder it is to apprehend. To my mind 80 columns is a nice upper limit: long enough for expressiveness, short enough to easily scan. Cheers, Cameron Simpson From steve at pearwood.info Tue Feb 19 04:59:57 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 19 Feb 2019 20:59:57 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: <20190219095957.GD4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 05:37:29AM +0100, Simon wrote: > Hello, > > I'd like to propose an update to PEP8. Indeed, the 80 characters per line > guideline is, I feel, outdated. I know this is not precisely what you are arguing, but the thought of people arguing that the only problem with a 300-character Perl one-liner is that their monitor is too narrow to view it amuses me :-) > I understand the need for it, back when monitors were small, and everyone > coded on terminals, but nowadays, I feel like that guideline is more of a > hinderance, and that it promotes poor code. The width of source code on old green-screen 80 column terminals may be a factor, but it probably isn't the most important factor. You might consider that even when broadsheet newspapers have up to 23 inches in width, they still format their text in much narrower columns. The typical line of text in a paperback is 60-70 characters including spaces. We have many centuries of experience teaching us that 60-70 columns of text is typically as wide as people can comfortably read. I'm not an expert, but my understanding is that the limiting factor is not so much the cognitive burden of reading 100+ characters but the physical motion of the eyes tracking back and forth across the long lines. The wider the line, the greater the chances that the eye will run off one line into the one below it, and the more eye-strain. Source code isn't as dense as prose, and is more line-oriented than paragraph-oriented, so we can afford to exceed 70 columns occasionally, but not too often. If people are regularly exceeding 80 columns, I would consider it a code smell and inspect the code carefully for these problems: - indents may be too wide (8 spaces instead of 4?); - code may be too deeply nested (too many indents); - variable names may be excessively long; - possibly too many violations of the Law of Demeter: paperboy.take_fee(customer.trousers.right_pocket.get_wallet().remove(fee)) - or just generally, too much complexity per line. > Indeed, people abiding by this rule tend to choose shorter variable names, > reduce the amount of indentation, and other tricks to just keep the > character count under 80. Do we? That's a rather sweeping generalisation. It may be true in some cases, but in other cases, the discipline of keeping to the 79 column limit can result in better code. But don't go mad about it: Raymond Hettinger did a very good talk called "Beyond PEP 8" which (correctly in my opinion) argues against worrying about small violations of PEP 8, in favour of more substantial efforts to beautify your code. https://www.youtube.com/watch?v=wf-BqAjZb8M In my own code, I take the 79 column limit as more of a guideline than a law, if I have to go over by 2 or 3 characters, I just do it and don't worry unless it is a more substantial violation. All those "tricks" you mention are not necessarily bad things, they can often be justified. If you have a function or method with eight levels of indentation, you probably should reduce the amount of indentation by refactoring. If you have variables like number_of_pages_in_current_section you probably should consider a shorter name. Your IDE may make it easy to write such long names, but it doesn't make it easy to read them. -- Steven From nicolas.rolin at tiime.fr Tue Feb 19 05:38:04 2019 From: nicolas.rolin at tiime.fr (Nicolas Rolin) Date: Tue, 19 Feb 2019 11:38:04 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <20190219095957.GD4465@ando.pearwood.info> References: <20190219095957.GD4465@ando.pearwood.info> Message-ID: I don't think you will find an agreement to raise the number of line length (we didn't even manage to find an agreement at my job with less than 10 people), so I would suggest every reader not interested in the disscussion to put it into the bin directly, as no decision will emerge from here. That beeing said, the probable best limit should be None, and let everyone's text editor line up the things the way people want to read them. > If you have variables like number_of_pages_in_current_section > you probably should consider a shorter name. Your IDE may make it easy > to write such long names, but it doesn't make it easy to read them. > I understand that the writer wants to have shorter names, but why would I want more ambigious names as a reader ? How would you rename number_of_pages_in_current_section such that the reader is not left wondering what does this variable represents ? -- *Nicolas Rolin* | Data Scientist + 33 631992617 - nicolas.rolin at tiime.fr *15 rue Auber, **75009 Paris* *www.tiime.fr * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sf at fermigier.com Tue Feb 19 06:23:06 2019 From: sf at fermigier.com (=?UTF-8?Q?St=C3=A9fane_Fermigier?=) Date: Tue, 19 Feb 2019 12:23:06 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> Message-ID: My two cents, because this is a subject about which I have a strong opinion: - Yes, VT100s and other green screen terminals have long since been out of fashion, but there are still some people, including myself, who like their xterms and iTerms in the standard size (80x24). Also, we sometime need to browser code from a smartphone, in which case physical (not just virtual) screen size is really an issue. - Yes, for maximum code readability, it's better to optimise for ~70 no whitespace characters max, which is approximately 80 characters overall if you you put space properly around / after commas, plusses, equals, etc. - OTOH: there is now a wonderful tool called Black ( https://github.com/ambv/black ) which is so good at turning badly formatted code into readable code that I've stopped worrying about this kind of issues (even though, as stated initially, I have a strong attachment to it). Black's default is 88, not 80, which conflicts a bit with the two previous points, but Black is, IMHO, so good that I've stopped thinking about it (there is a way to override the default setting, which I should be using, but I don't). Cheers, S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, Free&OSS Group @ Systematic Cluster - https://systematic-paris-region.org/fr/groupe-thematique-logiciel-libre/ Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.bordeyne at gmail.com Tue Feb 19 09:07:23 2019 From: simon.bordeyne at gmail.com (simon.bordeyne) Date: Tue, 19 Feb 2019 15:07:23 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: Message-ID: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> I find that 100 to 120 characters is ideal as far as line length goes. In my opinion, splitting lines is much worse in terms of cognitive burden than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels. All it takes is a loop in a loop (looping through an array for instance), a condition and all of that inside a class' method. Just in that example, which is a very common occurence, an doesn't warrant refactoring, there is 5 indentation level, eg a quarter of the recommended line length.?Defining decorators also goes up there in terms of number of indents by the way.?As far as monitor size goes, I agree that on a laptop is not ideal for 100+ characters per line if you want two pieces of code side by side. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. Both are perfectly fine with 100 characters a line.?A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable.?Envoy? depuis mon smartphone Samsung Galaxy. -------- Message d'origine --------De : David Mertz Date : 19/02/2019 07:28 (GMT+01:00) ? : Anders Hovm?ller Cc : Simon , python-ideas Objet : Re: [Python-ideas] PEP 8 update on line length 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure whitespace counts much less towards that burden than do regular characters. And to a significant degrees, punctuation vs. letters vs. numbers matter. And sure familiar words such as keywords scan a bit easier than unfamiliar names of variables. And so on.But 80 characters in general is already too wide most of the time. 65 is a better goal as a rule of thumb, with 80 already being for exceptionally long lines. Python keywords are already short, there's not much improvement to be had there. Saving two characters for acryptic WHL isn't better than the word 'while', for example.Pretty much the only time my code how's more than 80 characters is when it includes string literally that occupy a large chunk of the width. But if that 50 character string is the last argument of a function call, the reader can mostly stop scanning at it's beginning, so it's not terrible. When I have many keyword arguments, I break them into multiple physical lines using parents too continue the logical line. Or if I have complex compound conditions, I give the subclauses short but descriptive names before the if/elif.On Tue, Feb 19, 2019, 1:11 AM Anders Hovm?ller On 19 Feb 2019, at 05:48, David Mertz wrote: > > You either have much better eyes to read tiny fonts than I do, or maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop bag). > > But that's not even the real issue. If the characters were in giant letters on billboards, I still would never want more than 80 of them on a line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia of experience with writing show that cognitive burden goes up exponentially, not linearly, as lines get to be more than about 60 characters. If that is the issue then we should be talking about non-space characters, not a 68 column limit right? No way does 40 spaces due to indent count towards the cognitive burden :) Also, if the cognitive burden is the issue then we should talk about short forms for keyword arguments again. The way the 68 column limit works in practice is that people avoid keyword arguments because of line length, plus the issues already mentioned. / Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.f.moore at gmail.com Tue Feb 19 09:13:24 2019 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 19 Feb 2019 14:13:24 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: On Tue, 19 Feb 2019 at 14:08, simon.bordeyne wrote: > A good middle ground would be to enforce customization of that rule in the most used python linters. A simple setting to set the number of characters before a linting warning occurs would be acceptable. Any linter or project that treats PEP 8 as mandatory has *already* failed, as PEP 8 itself states that the rules can be broken as needed. Of course individual projects are entirely allowed to impose whatever draconian and inflexible rules they choose on source code formatting, but please don't pretend that PEP 8 made you do it ;-) Paul From j.orponen at 4teamwork.ch Tue Feb 19 09:14:21 2019 From: j.orponen at 4teamwork.ch (Joni Orponen) Date: Tue, 19 Feb 2019 15:14:21 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: On Tue, Feb 19, 2019 at 3:07 PM simon.bordeyne wrote: > A good middle ground would be to enforce customization of that rule in the > most used python linters. A simple setting to set the number of characters > before a linting warning occurs would be acceptable. > Major linters already support this. Some linters I know of having support: pycodestyle, pyflakes, isort, pylint, black. -- Joni Orponen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ijkl at netc.fr Tue Feb 19 09:13:14 2019 From: ijkl at netc.fr (Jimmy Girardet) Date: Tue, 19 Feb 2019 15:13:14 +0100 Subject: [Python-ideas] add fluent operator to everything Message-ID: Hi, There was the discussion about vector, etc... I think I have a frustration about chaining things easily in python in the stdlib where many libs like orm? do it great. Here an example : The code is useless, just to show the idea >>> a = [1,2,3] >>> a.append(4) >>> a.sort() >>> c = max(a) + 1 I would be happy to have >>> [1,2,3].append(4)::sort()::max() +1 It makes things very easy to read: first create list, then append 4, then sort, then get the max. To resume, the idea is to apply via a new operator (::, .., etc...) the following callable on the previous object. It's clearly? for standalone object or after a method call when the return is None (there is fluent? `.` when there is a return value) >> object::callable()? = callable(object) >> object(arg)::callable = callable(object(arg)) def callable(arg1,arg2): ?? pass >> object::callable(arg) == callable(object, arg) The idea is to use quite everything as first argument of any callable. I do not know if it was already discussed, and if it would be technically doable. Nice Day Jimmy From S at muelcolvin.com Tue Feb 19 09:28:57 2019 From: S at muelcolvin.com (Samuel Colvin) Date: Tue, 19 Feb 2019 14:28:57 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: I too would argue that it's time to reconsider line length limits. But the reason is not monitor changes, or any particularly strong personal opinion, but changes to python: Let's take a real life example from here (changed very slightly for this example), in tranitional python the signature might be: def resolve_annotations(raw_annotations, module_name): 55 characters, all fine. Now let's look at that same function in modern python with type hints: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: 119 characters! No daft 5-word variable names, just a clean (if strict) function definition. I don't see how anyone can say that would be more readable with a 80 character line limit. And that's not even an extreme case, we don't have lots of "Optional[..]" or "Tuple[ThingA, ThingB, ThingC]". Type hints (for good or bad depending on your view point) have made python code more verbose, that's just a fact. Code that used to fit on one line with 80char limit now require 120 (or more), therefore in my opinion the recommendation should change to keep up with changes in python. My preference is 120 characters (that's also the default in pycharm I believe). It works well on a desktop monitor, leaving room for a file browser and part of another window, it's also fine on a 13" laptop screen. Then again, every IDE and linter I've used (even black) allows the line length to be varried, so this is only really a problem in the standard library and libraries which adhere closely to pep8. Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Tue Feb 19 09:30:31 2019 From: mertz at gnosis.cx (David Mertz) Date: Tue, 19 Feb 2019 09:30:31 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: On Tue, Feb 19, 2019, 9:07 AM simon.bordeyne I find that 100 to 120 characters is ideal as far as line length goes. > I very much hope no one else where had to read it review your code. In my opinion, splitting lines is much worse in terms of cognitive burden > than just a longer line. On top of that, it's not uncommon to reach 6, even > 7 indentation levels. > In 20+ years of programming in Python (writing some will known books about it too), I have never once indented a block 7 levels. Very, very rarely 6. If you do that, your code has serious problems beyond line length. As far as monitor size goes, I agree that on a laptop is not ideal for 100+ > characters per line if you want two pieces of code side by side. > In a readable size and font, I get two vertical panes of 71 characters on my 15" Retina display. I can read a smaller font character by character, but not easily scan a line. Here I'm just taking about visual accuity, not the cognitive issue. My vision in particular remains 20/20 for near vision (but sadly decayed with age for distance). It used to be more like 20/15, but I never used lines longer than 80 characters in any programming language (yes, individual lines, but not as a rule). I did used to use a somewhat smaller font size though. I guarantee that your code quidditch would improve if you use both shorter lines and a larger font. The latter only affects your interaction with your screens, the former is essential to everyone who needs to look at your code. And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. > Both are perfectly fine with 100 characters a line. > > A good middle ground would be to enforce customization of that rule in the > most used python linters. A simple setting to set the number of characters > before a linting warning occurs would be acceptable. > Every linter I know about is customizable this way. > > > Envoy? depuis mon smartphone Samsung Galaxy. > > -------- Message d'origine -------- > De : David Mertz > Date : 19/02/2019 07:28 (GMT+01:00) > ? : Anders Hovm?ller > Cc : Simon , python-ideas < > python-ideas at python.org> > Objet : Re: [Python-ideas] PEP 8 update on line length > > 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure > whitespace counts much less towards that burden than do regular characters. > And to a significant degrees, punctuation vs. letters vs. numbers matter. > And sure familiar words such as keywords scan a bit easier than unfamiliar > names of variables. And so on. > > But 80 characters in general is already too wide most of the time. 65 is a > better goal as a rule of thumb, with 80 already being for exceptionally > long lines. Python keywords are already short, there's not much improvement > to be had there. Saving two characters for acryptic WHL isn't better than > the word 'while', for example. > > Pretty much the only time my code how's more than 80 characters is when it > includes string literally that occupy a large chunk of the width. But if > that 50 character string is the last argument of a function call, the > reader can mostly stop scanning at it's beginning, so it's not terrible. > When I have many keyword arguments, I break them into multiple physical > lines using parents too continue the logical line. Or if I have complex > compound conditions, I give the subclauses short but descriptive names > before the if/elif. > > On Tue, Feb 19, 2019, 1:11 AM Anders Hovm?ller >> >> >> > On 19 Feb 2019, at 05:48, David Mertz wrote: >> > >> > You either have much better eyes to read tiny fonts than I do, or maybe >> a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop >> bag). >> > >> > But that's not even the real issue. If the characters were in giant >> letters on billboards, I still would never want more than 80 of them on a >> line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia >> of experience with writing show that cognitive burden goes up >> exponentially, not linearly, as lines get to be more than about 60 >> characters. >> >> If that is the issue then we should be talking about non-space >> characters, not a 68 column limit right? No way does 40 spaces due to >> indent count towards the cognitive burden :) >> >> Also, if the cognitive burden is the issue then we should talk about >> short forms for keyword arguments again. The way the 68 column limit works >> in practice is that people avoid keyword arguments because of line length, >> plus the issues already mentioned. >> >> / Anders > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Tue Feb 19 09:34:10 2019 From: mertz at gnosis.cx (David Mertz) Date: Tue, 19 Feb 2019 09:34:10 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: Wow... Sorry about all my typos from autocorrect. I should not write a longish reply on my tablet, or should proofread and correct. On Tue, Feb 19, 2019, 9:30 AM David Mertz On Tue, Feb 19, 2019, 9:07 AM simon.bordeyne wrote: > >> I find that 100 to 120 characters is ideal as far as line length goes. >> > > I very much hope no one else where had to read it review your code. > > In my opinion, splitting lines is much worse in terms of cognitive burden >> than just a longer line. On top of that, it's not uncommon to reach 6, even >> 7 indentation levels. >> > > In 20+ years of programming in Python (writing some will known books about > it too), I have never once indented a block 7 levels. Very, very rarely 6. > If you do that, your code has serious problems beyond line length. > > As far as monitor size goes, I agree that on a laptop is not ideal for >> 100+ characters per line if you want two pieces of code side by side. >> > > In a readable size and font, I get two vertical panes of 71 characters on > my 15" Retina display. I can read a smaller font character by character, > but not easily scan a line. > > Here I'm just taking about visual accuity, not the cognitive issue. My > vision in particular remains 20/20 for near vision (but sadly decayed with > age for distance). It used to be more like 20/15, but I never used lines > longer than 80 characters in any programming language (yes, individual > lines, but not as a rule). I did used to use a somewhat smaller font size > though. > > I guarantee that your code quidditch would improve if you use both shorter > lines and a larger font. The latter only affects your interaction with your > screens, the former is essential to everyone who needs to look at your code. > > And, fyi, I work on a 23" monitor at home and on a 15.6" monitor on the >> go. Both are perfectly fine with 100 characters a line. >> >> A good middle ground would be to enforce customization of that rule in >> the most used python linters. A simple setting to set the number of >> characters before a linting warning occurs would be acceptable. >> > > Every linter I know about is customizable this way. > > >> >> >> Envoy? depuis mon smartphone Samsung Galaxy. >> >> -------- Message d'origine -------- >> De : David Mertz >> Date : 19/02/2019 07:28 (GMT+01:00) >> ? : Anders Hovm?ller >> Cc : Simon , python-ideas < >> python-ideas at python.org> >> Objet : Re: [Python-ideas] PEP 8 update on line length >> >> 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure >> whitespace counts much less towards that burden than do regular characters. >> And to a significant degrees, punctuation vs. letters vs. numbers matter. >> And sure familiar words such as keywords scan a bit easier than unfamiliar >> names of variables. And so on. >> >> But 80 characters in general is already too wide most of the time. 65 is >> a better goal as a rule of thumb, with 80 already being for exceptionally >> long lines. Python keywords are already short, there's not much improvement >> to be had there. Saving two characters for acryptic WHL isn't better than >> the word 'while', for example. >> >> Pretty much the only time my code how's more than 80 characters is when >> it includes string literally that occupy a large chunk of the width. But if >> that 50 character string is the last argument of a function call, the >> reader can mostly stop scanning at it's beginning, so it's not terrible. >> When I have many keyword arguments, I break them into multiple physical >> lines using parents too continue the logical line. Or if I have complex >> compound conditions, I give the subclauses short but descriptive names >> before the if/elif. >> >> On Tue, Feb 19, 2019, 1:11 AM Anders Hovm?ller > wrote: >> >>> >>> >>> > On 19 Feb 2019, at 05:48, David Mertz wrote: >>> > >>> > You either have much better eyes to read tiny fonts than I do, or >>> maybe a much larger monitor (it's hard for me to fit a 30"" monitor in my >>> laptop bag). >>> > >>> > But that's not even the real issue. If the characters were in giant >>> letters on billboards, I still would never want more than 80 of them on a >>> line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia >>> of experience with writing show that cognitive burden goes up >>> exponentially, not linearly, as lines get to be more than about 60 >>> characters. >>> >>> If that is the issue then we should be talking about non-space >>> characters, not a 68 column limit right? No way does 40 spaces due to >>> indent count towards the cognitive burden :) >>> >>> Also, if the cognitive burden is the issue then we should talk about >>> short forms for keyword arguments again. The way the 68 column limit works >>> in practice is that people avoid keyword arguments because of line length, >>> plus the issues already mentioned. >>> >>> / Anders >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Tue Feb 19 09:41:27 2019 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 20 Feb 2019 01:41:27 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> Message-ID: On Tue, Feb 19, 2019 at 9:38 PM Nicolas Rolin wrote: > I understand that the writer wants to have shorter names, but why would I want more ambigious names as a reader ? > How would you rename number_of_pages_in_current_section such that the reader is not left wondering what does this variable represents ? page_count will usually be unambiguous. You might need total_pages to mean "not the current section", thus leaving the shorter one available for the narrower use. Obviously questions like this can't be answered without context, but at an absolute minimum, "number_of" can almost *always* be omitted. ChrisA From boxed at killingar.net Tue Feb 19 09:45:42 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Feb 2019 15:45:42 +0100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: Message-ID: <93B5FE69-4554-4E1A-AF87-68B3301F74CB@killingar.net> I would suggest a small improvement: allow a trailing :: which is useful for when the last function does not return anything. So for example this [1,2,3].append(4)::sort() will evaluate to None, but [1,2,3].append(4)::sort():: would evaluate to the list. > On 19 Feb 2019, at 15:13, Jimmy Girardet wrote: > > Hi, > > There was the discussion about vector, etc... > > I think I have a frustration about chaining things easily in python in > the stdlib where many libs like orm do it great. > > Here an example : > > The code is useless, just to show the idea > >>>> a = [1,2,3] > >>>> a.append(4) > >>>> a.sort() > >>>> c = max(a) + 1 > > > I would be happy to have > >>>> [1,2,3].append(4)::sort()::max() +1 > > It makes things very easy to read: first create list, then append 4, > then sort, then get the max. > > To resume, the idea is to apply via a new operator (::, .., etc...) the > following callable on the previous object. It's clearly for standalone > object or after a method call when the return is None (there is fluent > `.` when there is a return value) > >>> object::callable() = callable(object) >>> object(arg)::callable = callable(object(arg)) > > def callable(arg1,arg2): > pass > >>> object::callable(arg) == callable(object, arg) > > The idea is to use quite everything as first argument of any callable. > > I do not know if it was already discussed, and if it would be > technically doable. > > Nice Day > Jimmy > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From rosuav at gmail.com Tue Feb 19 09:54:44 2019 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 20 Feb 2019 01:54:44 +1100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: Message-ID: On Wed, Feb 20, 2019 at 1:22 AM Jimmy Girardet wrote: > >>> a = [1,2,3] > >>> a.append(4) > >>> a.sort() > >>> c = max(a) + 1 > > I would be happy to have > >>> [1,2,3].append(4)::sort()::max() +1 > > It makes things very easy to read: first create list, then append 4, > then sort, then get the max. > > To resume, the idea is to apply via a new operator (::, .., etc...) the > following callable on the previous object. It's clearly for standalone > object or after a method call when the return is None (there is fluent > `.` when there is a return value) Hmm. The trouble is, there's no consistent "previous object" for each of your steps. You're mixing together "max()" which is a built-in, and "sort()" which is a method. Your proposed semantics (which I snipped) will happily cover built-ins, but not methods. Proposals broadly similar to these (but generally, if my memory serves, focusing on methods only) have come up periodically. You may want to briefly search the mailing list archives to find discussions on "method chaining". ChrisA From 2QdxY4RzWzUUiLuE at potatochowder.com Tue Feb 19 10:13:06 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Tue, 19 Feb 2019 09:13:06 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: On 2/19/19 8:28 AM, Samuel Colvin wrote: > Let's take a real life example from here > > (changed very slightly for this example), in tranitional python the > signature might be: > > def resolve_annotations(raw_annotations, module_name): > > 55 characters, all fine. Now let's look at that same function in > modern python with type hints: > > def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: If it were me, I'd probably write (or would have re-written when I added the type hints) that as follows: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str] ) -> Dict[str, Type[Any]]: which leaves the longest line at 46 characters, even shorter than your original 55. And if the type hints are long, then a similar approach can mitigate that: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str] ) -> Dict[str, Type[Any]]: > Type hints (for good or bad depending on your view point) have made > python code more verbose, that's just a fact. Code that used to fit on > one line with 80char limit now require 120 (or more), therefore in my > opinion the recommendation should change to keep up with changes in > python. Nothing says that you have to write an entire function header on one line. From S at muelcolvin.com Tue Feb 19 10:28:05 2019 From: S at muelcolvin.com (Samuel Colvin) Date: Tue, 19 Feb 2019 15:28:05 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: > Nothing says that you have to write an entire function header on one line. Of course. I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header. For example: it's less likely that two chunks of code I'm looking at are still visible on the screen at the same time in the former case. I'm simply arguing that since python has changed, it might make sense to change this recomendation too. That what would have been on one line in 2000 should still be on one line in 2019, despite changes to the language. I'm going to leave this conversation now as it seem to be primarily opinion based and I generally find opinion based discussions almost as annoying as meta-conversations about how the list should be run. :-) Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfine2358 at gmail.com Tue Feb 19 10:54:22 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Tue, 19 Feb 2019 15:54:22 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dict[str, AnyType], module_name: Optional[str], ) -> Dict[str, AnyType]: pass -- Jonathan From S at muelcolvin.com Tue Feb 19 11:01:15 2019 From: S at muelcolvin.com (Samuel Colvin) Date: Tue, 19 Feb 2019 16:01:15 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: I'm afraid I'm not sure of your point here. (By the way, that code is already run through black, just with a line length limit of 120) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pander at users.sourceforge.net Tue Feb 19 11:00:46 2019 From: pander at users.sourceforge.net (Pander) Date: Tue, 19 Feb 2019 17:00:46 +0100 Subject: [Python-ideas] Support localization of unicode descriptions In-Reply-To: References: Message-ID: On 7/11/18 1:14 AM, Terry Reedy wrote: > On 7/10/2018 5:20 PM, David Mertz wrote: >> The problem with non-canonical translations of the Unicode character >> names is that there is not one unique possible rendering into >> language X. Equally, I could find synonyms in general English for the >> names, but one would be official, the others at best informally >> clarifying. > > If the Unicode consortium does not provide official translations, then > we *might* 'bless' some other source.? The first place I would look > would be the translators we already trust enough to display their work > on the official doc page. > >> For informational purposes I think it's great to have a third party >> project to find out "Unicode character named 'Something In English' >> is roughly translated as in your native language." But >> it's hard to see how an unofficial loose cross-language dictionary >> should be party of the standard library. > > The doc translations are intentionally not in the cpython repository > and not in the cpython distribution and not considered part of the > stdlib. In general, core devs have no particular expertise, interest, > or time to vet translators and review translations. > > A proposal to make turtle a package and put translations of turtle > commands in a submodule got no traction.? "Put it on Pypi" > > I have rejected proposals to put translations of IDLE's menus in an > idlelib subdirectory, to be distributed with cpython as 'part' of the > stdlib.? I am thinking about various ideas to allow users to customize > the menu, either by editing a file or processing a download.? (For > instance, the Japanese doc translation includes the IDLE chapter, > which has a list of menu items and descriptions.)? But this is a > different issue. > > The repository for unicode description translations should also be > other than the cpython repository. I have made the following collection of scripts https://github.com/OpenTaal/python-unicodedata_l10n as a start for offering l18n support. At the moment, there are only a few languages with a wide coverage of translations, but that is progressing slowly at https://unicode-table.com/ I made it so that PO and MO files are being generated. In order to package and publish this on e.g. PyPI, I'm looking for someone who has more experience in that area. > >> On Tue, Jul 10, 2018, 5:11 PM Terry Reedy > > wrote: >> >> ??? On 7/10/2018 4:45 AM, Pander wrote: >> >> ???? > This is a third party initiative. The translations are >> contributed by >> ???? > volunteers. I have talked with Python core developers and they >> ??? suggested >> ???? > to post this here, as it is for them out of scope for Python >> std lib. >> >> ??? Python-ideas list is for discussion of python and the stdlib >> library. >> ??? This is not a place for prolonged discussion of pypi projects. >> ??? It *is* a place to discuss adding a hook that can be used to access >> ??? translations. >> >> ??? There are both official doc translations, accessible from the >> official >> ??? doc pages, and others that are independent.? The official ones, at >> ??? least, are discussed on the doc-sig list >> ??? https://mail.python.org/mailman/listinfo/doc-sig >> ??? There are currently 7 languages and coordinators listed at >> ??? https://devguide.python.org/experts/#documentation-translations >> ??? 4 have progressed far enough to be listed in the drop-down box on >> ??? https://docs.python.org/3/ >> >> ??? I should think that these people should be asked if they want to be >> ??? involved with unicode description translations.? They should >> certainly >> ??? have some helpful advice. >> >> ??? The description vocabulary is rather restricted, so a word >> translation >> ??? dictionary should be pretty easy.? For at least for some >> languages, it >> ??? should be possible to generate the 200000 description >> translations from >> ??? this. The main issues are word order and language-dependent 'word' >> ??? units.? Hence, the three English words "LATIN SMALL LETTER" >> become two >> ??? words in German, 'LATEINISCHER KLEINBUCHSTABE', versus three >> words in >> ??? Spanish, but in reverse order, 'LETRA PEQUE?A LATINA'.? It is >> possible >> ??? that the doc translators already uses translation software that deal >> ??? with these issues. > > From boxed at killingar.net Tue Feb 19 11:26:37 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Feb 2019 17:26:37 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: > If it were me, I'd probably write (or would have re-written when I added > the type hints) that as follows: > > def resolve_annotations( > *, > raw_annotations: Dict[str, Type[Any]], > module_name: Optional[str] > ) -> Dict[str, Type[Any]]: I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) I would vastly prefer a soft like break algorithm that formatted the code as per your examples and having the code on disk be single line no matter what. In proprietary projects where one can agree on the tools used for the code this can be quite doable, but I agree it's not great for open source projects. / Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhodri at kynesim.co.uk Tue Feb 19 11:36:19 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Tue, 19 Feb 2019 16:36:19 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> On 19/02/2019 16:26, Anders Hovm?ller wrote: > >> If it were me, I'd probably write (or would have re-written when I added >> the type hints) that as follows: >> >> def resolve_annotations( >> *, >> raw_annotations: Dict[str, Type[Any]], >> module_name: Optional[str] >> ) -> Dict[str, Type[Any]]: > > I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) How odd. I always break up long lines like this, and I've never once had an issue grepping. -- Rhodri James *-* Kynesim Ltd From boxed at killingar.net Tue Feb 19 12:06:57 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Feb 2019 18:06:57 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> Message-ID: <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> > On 19 Feb 2019, at 17:36, Rhodri James wrote: > > On 19/02/2019 16:26, Anders Hovm?ller wrote: >>> If it were me, I'd probably write (or would have re-written when I added >>> the type hints) that as follows: >>> >>> def resolve_annotations( >>> *, >>> raw_annotations: Dict[str, Type[Any]], >>> module_name: Optional[str] >>> ) -> Dict[str, Type[Any]]: >> I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) > > How odd. I always break up long lines like this, and I've never once had an issue grepping. Maybe you know some grep magic I don't? Is there a way to do multi line grep that knows that open paren means to ignore new lines until the matching close paren? I'd love to hear about it! / Anders From mal at egenix.com Tue Feb 19 12:12:23 2019 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 19 Feb 2019 18:12:23 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> Message-ID: On 19.02.2019 18:06, Anders Hovm?ller wrote: > > >> On 19 Feb 2019, at 17:36, Rhodri James wrote: >> >> On 19/02/2019 16:26, Anders Hovm?ller wrote: >>>> If it were me, I'd probably write (or would have re-written when I added >>>> the type hints) that as follows: >>>> >>>> def resolve_annotations( >>>> *, >>>> raw_annotations: Dict[str, Type[Any]], >>>> module_name: Optional[str] >>>> ) -> Dict[str, Type[Any]]: >>> I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) >> >> How odd. I always break up long lines like this, and I've never once had an issue grepping. > > Maybe you know some grep magic I don't? Is there a way to do multi line grep that knows that open paren means to ignore new lines until the matching close paren? I'd love to hear about it! This should help: https://stackoverflow.com/questions/3717772/regex-grep-for-multi-line-search-needed but you can also use Python's re module with the re.DOTALL flag. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 19 2019) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From rhodri at kynesim.co.uk Tue Feb 19 12:12:38 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Tue, 19 Feb 2019 17:12:38 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> Message-ID: <03cef93b-e768-8358-a2f2-17ecbff62d15@kynesim.co.uk> On 19/02/2019 17:06, Anders Hovm?ller wrote: > > >> On 19 Feb 2019, at 17:36, Rhodri James wrote: >> >> On 19/02/2019 16:26, Anders Hovm?ller wrote: >>>> If it were me, I'd probably write (or would have re-written when I added >>>> the type hints) that as follows: >>>> >>>> def resolve_annotations( >>>> *, >>>> raw_annotations: Dict[str, Type[Any]], >>>> module_name: Optional[str] >>>> ) -> Dict[str, Type[Any]]: >>> I would like to point out here that breaking up a line breaks grepping quite badly. I've had to write AST-based searches to find simple usages of arguments in the code base at work precisely because of code that is split on likes like this. (This tool is available here: https://github.com/boxed/parso_utils) >> >> How odd. I always break up long lines like this, and I've never once had an issue grepping. > > Maybe you know some grep magic I don't? Is there a way to do multi line grep that knows that open paren means to ignore new lines until the matching close paren? I'd love to hear about it! I probably don't know any more grep magic than you, I've just never had cause to grep for anything that long. I am a touch bemused that you do frequently have cause, but each to his own, I suppose. -- Rhodri James *-* Kynesim Ltd From 2QdxY4RzWzUUiLuE at potatochowder.com Tue Feb 19 12:15:29 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Tue, 19 Feb 2019 11:15:29 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> Message-ID: On 2/19/19 11:06 AM, Anders Hovm?ller wrote: > Maybe you know some grep magic I don't? Is there a way to> do multi > line grep that knows that open paren means to ignore new lines until > the matching close paren? I'd love to hear about it! At the risk of jumping in over my head with respect to the technical limitations of regular expressions, grep already can't deal with matching parenthesis. Consider: f(g(h(a=4), b=5), c=6) Can grep tell me that I'm passing c to f but not to g or h? Disclaimer: I don't write code like that. Most of the time. From jfine2358 at gmail.com Tue Feb 19 12:29:33 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Tue, 19 Feb 2019 17:29:33 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: Previously, Samuel wrote that he would leave the conversation, because it was primarily opinion based, which he finds annoying. I then provided evidence (namely how black.py reformats a specific code example). Samuel then wrote: > I'm afraid I'm not sure of your point here. I wasn't making a point. I was providing evidence. -- Jonathan From boxed at killingar.net Tue Feb 19 13:09:00 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Tue, 19 Feb 2019 19:09:00 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <03cef93b-e768-8358-a2f2-17ecbff62d15@kynesim.co.uk> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <2d5860be-a1c5-ad16-cc8e-52ca64362866@kynesim.co.uk> <0F483D1F-C8D9-4F53-BDE4-18F84E2AD939@killingar.net> <03cef93b-e768-8358-a2f2-17ecbff62d15@kynesim.co.uk> Message-ID: <76D47038-DD96-4572-8069-98094387332F@killingar.net> >> Maybe you know some grep magic I don't? Is there a way to do multi line grep that knows that open paren means to ignore new lines until the matching close paren? I'd love to hear about it! > > I probably don't know any more grep magic than you, I've just never had cause to grep for anything that long. I am a touch bemused that you do frequently have cause, but each to his own, I suppose. Not often. Once. But then I really really needed it :) It was a case where we had an API change to a lib and many calls where long enough to be split on multiple lines AND the keyword argument we had to find was very generic AND it could exist in nested calls. Of course the last was really fine since we could ha e worked through the false positives manually. I also happen to have lots of experience with Parso so it was easy for me to write. Otherwise we would probably have a logged through the crappy way. It's pretty nice to have this is the tool belt though. / Anders From miikka.salminen at gmail.com Tue Feb 19 16:05:55 2019 From: miikka.salminen at gmail.com (Miikka Salminen) Date: Tue, 19 Feb 2019 23:05:55 +0200 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions Message-ID: Hi! To help automatic document generators and static type checkers reason more about the code, the possible side-effects and raised exceptions could also be annotated in a standardized way. I'll let some example code talk on my behalf. Here's a simple decorator for annotating exceptions: In [1]: import typing as t In [2]: def raises(exc: Exception) -> t.Callable: ...: def decorator(fn: t.Callable) -> t.Callable: ...: fn.__annotations__["__raises__"] = exc ...: return fn ...: return decorator ...: In [3]: @raises(ValueError) ...: def hello_if_5(x: int) -> None: ...: if x != 5: ...: raise ValueError("number other than 5 given") ...: print("Hello!") ...: In [4]: hello_if_5.__annotations__ Out[4]: {'x': int, 'return': None, '__raises__': ValueError} In [5]: hello_if_5(1) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in ----> 1 hello_if_5(1) in hello_if_5(x) 2 def hello_if_5(x: int) -> None: 3 if x != 5: ----> 4 raise ValueError("number other than 5 given") 5 print("Hello!") 6 ValueError: number other than 5 given In [6]: hello_if_5(5) Hello! In [7]: and here's a simple decorator for annotating side-effects: In [1]: import typing as t In [2]: def side_effect(has_side_effect: bool) -> t.Callable: ...: def decorator(fn: t.Callable) -> t.Callable: ...: fn.__annotations__["__side_effect__"] = has_side_effect ...: return fn ...: return decorator ...: In [3]: a = 10 In [4]: @side_effect(True) ...: def change_a(val: int) -> None: ...: global a ...: a = val ...: In [5]: change_a.__annotations__ Out[5]: {'val': int, 'return': None, '__side_effect__': True} In [6]: change_a(100) In [7]: a Out[7]: 100 In [8]: @side_effect(True) ...: def mutate_list(items: t.List) -> None: ...: items.append("new item") ...: In [9]: mutate_list.__annotations__ Out[9]: {'items': typing.List, 'return': None, '__side_effect__': True} In [10]: l = ["old item"] In [11]: mutate_list(l) In [12]: l Out[12]: ['old item', 'new item'] In [13]: The example implementations have some obvious limitations, such as only allowing one error type. What do you think of the idea in general? Do you feel this is something that could be included in Python? typing would probably be a good module to store such decorators, I guess? Miikka Salminen miikka.salminen at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Tue Feb 19 16:37:19 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 20 Feb 2019 10:37:19 +1300 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: <5C6C770F.6000704@canterbury.ac.nz> Samuel Colvin wrote: > def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: > > I don't see how anyone can say that would be more > readable with a 80 character line limit. I would argue that it *is* more readable if it's not all on one line: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: Having thus improved its readability, an 80-char line limit is no longer a problem. -- Greg From greg.ewing at canterbury.ac.nz Tue Feb 19 16:44:37 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 20 Feb 2019 10:44:37 +1300 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: <5C6C78C5.1000007@canterbury.ac.nz> Samuel Colvin wrote: > I just think that code with a 7 line function header is much > harder to read and understand than code with a one line function header. But to me, a one-line function header that contains 7 lines worth of charaacters is *less* readable than a 7-line header, as long as it's formatted intelligently. The readability problem here is not caused by insufficient width. It's caused by the need to stuff a bunch of annotations into the header. -- Greg From brett at python.org Tue Feb 19 16:52:34 2019 From: brett at python.org (Brett Cannon) Date: Tue, 19 Feb 2019 13:52:34 -0800 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: Message-ID: On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote: > Hi, > > There was the discussion about vector, etc... > > I think I have a frustration about chaining things easily in python in > the stdlib where many libs like orm do it great. > > Here an example : > > The code is useless, just to show the idea > > >>> a = [1,2,3] > > >>> a.append(4) > > >>> a.sort() > > >>> c = max(a) + 1 > > > I would be happy to have > > >>> [1,2,3].append(4)::sort()::max() +1 > > It makes things very easy to read: first create list, then append 4, > then sort, then get the max. > Easy for you, but not necessarily everyone else. For instance, I find the explicit writing out of the lines easier. Also realize that design is on purpose so that mutating method calls on lists do not return themselves to get the point across that the mutation was in-place and not in fact a new list. -Brett > > To resume, the idea is to apply via a new operator (::, .., etc...) the > following callable on the previous object. It's clearly for standalone > object or after a method call when the return is None (there is fluent > `.` when there is a return value) > > >> object::callable() = callable(object) > >> object(arg)::callable = callable(object(arg)) > > def callable(arg1,arg2): > pass > > >> object::callable(arg) == callable(object, arg) > > The idea is to use quite everything as first argument of any callable. > > I do not know if it was already discussed, and if it would be > technically doable. > > Nice Day > Jimmy > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertve92 at gmail.com Tue Feb 19 17:07:36 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Tue, 19 Feb 2019 23:07:36 +0100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: Message-ID: Heyy, it's funcoperators idea ! >>> [1,2,3].append(4)::sort()::max() +1 [1, 2, 3] |append(4) |to(sorted) |to(max) |to(plus1) You just have to : pip install funcoperators from funcoperators import postfix as to plus1 = postfix(lambda x: x+1) from funcoperators import postfix def append(x): return postfix(lambda L: L + [x]) The module also propose a way to have infix operators, so if you want to have the "::" operator that have the same precedence than "/", you could call it "/ddot/" and do : [1,2,3] /ddot/ append(4) /ddot/ sort /ddot/ max +1 But for your case (creating Bash like "pipes" the above solution seems better). https://pypi.org/project/funcoperators/ PS: you could create "modify and return" version of "append" or "sort" like this : def append(x): @postfix def new(L): L.append(x) return L return new Then you'd have : >>> a = [1,2,3] >>> b = a |append(5) |append(6) >>> a is b True -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue Feb 19 18:16:21 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 20 Feb 2019 10:16:21 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: <20190219231620.GF4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 02:13:24PM +0000, Paul Moore wrote: > Any linter or project that treats PEP 8 as mandatory has *already* > failed, as PEP 8 itself states that the rules can be broken as needed. > Of course individual projects are entirely allowed to impose whatever > draconian and inflexible rules they choose on source code formatting, > but please don't pretend that PEP 8 made you do it ;-) +1 QOTW Thank you Paul. -- Steven From steve at pearwood.info Tue Feb 19 18:12:48 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 20 Feb 2019 10:12:48 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: <20190219231247.GE4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 11:05:55PM +0200, Miikka Salminen wrote: > Hi! > > To help automatic document generators and static type checkers reason more > about the code, the possible side-effects and raised exceptions could also > be annotated in a standardized way. This is Python. Nearly everything could have side-effects or raise exceptions *wink* Despite the wink, I am actually serious. I fear that this is not compatible with duck-typing. Take this simple example: @raises(TypeError) def maximum(values:Iterable)->Any: it = iter(values) try: biggest = next(it) except StopIteration: return None for x in it: if x > biggest: biggest = x return x But in fact this code can raise anything, or have side-effects, since it calls x.__gt__ and that method could do anything. So our decoration about raising TypeError is misleading if you read it as "this is the only exception the function can raise". You should read it as "this promises to sometimes raise TypeError, but could raise any other exception as well". This pretty much shows that the idea of checked exceptions doesn't go well with Python's duck-typing. And I note that in Java, where the idea of checked exceptions originated, it turned out to be full of problems and a very bad idea. Here is your example: > In [3]: @raises(ValueError) > ...: def hello_if_5(x: int) -> None: > ...: if x != 5: > ...: raise ValueError("number other than 5 given") > ...: print("Hello!") In this *trivial* function, we can reason that there are no other possible exceptions (unless ValueError or print are monkey-patched or shadowed). But how many of your functions are really that simple? I would expect very few. For the vast majority of cases, any time you decorate a non-trivial function with "raises(X)", it needs to be read as "can raise X, or any other exception". And similarly with annotating functions for side-effects. I expect that most functions need to be read as "may have side-effects" even if annotated as side-effect free. So the promises made will nearly always be incredibly weak: - raises(A) means "may raise A, or any other unexpected exception" - sideeffects(True) means "may have expected side-effects" - sideeffects(False) means "may have unexpected side-effects" I don't think there is much value in a static checker trying to reason about either. (And the experience of Java tells us that checking exceptions is a bad idea even when enforced by the compiler.) If I'm right, then adding support for this to the std lib is unnecessary. But I could be wrong, and I encourage static checkers to experiment. To do so, they don't need support from the std lib. They can provide their own decorator, or use a comment: # raises ValueError, TypeError # +sideeffects def spam(): ... -- Steve From rosuav at gmail.com Tue Feb 19 18:25:51 2019 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 20 Feb 2019 10:25:51 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: <20190219231247.GE4465@ando.pearwood.info> References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 10:18 AM Steven D'Aprano wrote: > So the promises made will nearly always be incredibly weak: > > - raises(A) means "may raise A, or any other unexpected exception" > - sideeffects(True) means "may have expected side-effects" > - sideeffects(False) means "may have unexpected side-effects" Perhaps, but sometimes it's nice to know that a function is not intended to have any side effects. For instance, I'm currently working on some code that has a bunch of lines like this: type = _decode("WeaponTypes" if is_weapon else "ItemTypes") balance = _decode("BalanceDefs") brand = _decode("Manufacturers") Suppose we decide that the "balance" variable isn't being used anywhere. Is it okay to not decode the BalanceDefs? Nope, it isn't, because the decoding is done sequentially, which means that omitting one will leave all the subsequent ones desynchronized. Knowing that a function has no intentional side effects (which is weaker than declaring that it's a pure function) may well be useful when refactoring a messy codebase. (A messy codebase, such as the one that I was reading through when building that code. It's not code I'm intrinsically proud of, but I can say with confidence that it is WAY cleaner than the reference code. And if I'd been able to ascertain which functions were pure, or at least side-effect-free, it would have saved me a lot of hassle.) ChrisA From pbergen at salesforce.com Tue Feb 19 18:28:14 2019 From: pbergen at salesforce.com (Philip Bergen) Date: Tue, 19 Feb 2019 15:28:14 -0800 Subject: [Python-ideas] About PEP-582 Message-ID: First attempt at this, so please be gentle. :) I am very interested in the overall goal of not needing virtualenvs, but I'm curious about the motivations behind pep-582. Could someone help me understand if this has previously been discussed and in that case why it was decided against? 1: Why only look in CWD and not traverse root-wise? 2: It feels to me like there is a larger story here about sprucing up PYTHONPATH. About 2) I would prefer if we had a mechanism to automatically look for .pythonpath.pth (or something with a better name, but to that effect). Then we were not limited to a specific directory or location. This would streamline cross project repos, for instance: you could have docker images that came preloaded with common libraries and just add a layer with your specifics in a different directory earlier in the paths specified by .pythonpath.pth Using pip to install into your directories of choice is already supported, although perhaps we should have some way of telling it to use the first entry in .pythonpath.pth. I would be very grateful for some interaction on this. If there is general interest I could submit some working code. Thanks, // Phil -- *Philip Bergen* P: +1(415)200-7340 *"Without data you are just another person with an opinion" -- W. Edwards Deming* -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Tue Feb 19 18:29:15 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 20 Feb 2019 10:29:15 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: <20190219232914.GG4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 05:29:33PM +0000, Jonathan Fine wrote: > Previously, Samuel wrote that he would leave the conversation, because > it was primarily opinion based, which he finds annoying. > > I then provided evidence (namely how black.py reformats a specific > code example). > > Samuel then wrote: > > I'm afraid I'm not sure of your point here. > > I wasn't making a point. I was providing evidence. Evidence of what? What was the point of this evidence? If it was to demonstrate that it is possible to reformat function parameter lists to split over multiple lines, we already knew that. If it was to demonstrate something else, I have no idea what. -- Steven From steve at pearwood.info Tue Feb 19 19:12:03 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 20 Feb 2019 11:12:03 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> Message-ID: <20190220001203.GH4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 11:38:04AM +0100, Nicolas Rolin wrote: > I understand that the writer wants to have shorter names, but why would I > want more ambigious names as a reader ? > How would you rename number_of_pages_in_current_section such that the > reader is not left wondering what does this variable represents ? Excellent question! Note that I didn't say that long names are *necessarily* a problem, only that they could be. I would start by reading the code and asking two questions: 1. Does the name really need to specify that it is the number of pages in the *current* section? Unless you have multiple such variables: number_of_pages_in_current_section number_of_pages_in_previous_section number_of_pages_in_next_section the chances are very good that "in_current_section" is pointless information that the reader will infer from context: for section in sections: number_of_pages = len(section) 2. Do you really need such a verbose name spelled out in full? Instead of "number_of_pages", perhaps "num_pages" is enough. If it is obvious from context, perhaps even "num" or even "n" is enough. If you dislike such standard abbrevations, how about "pagecount"? Short names are not necessarily ambiguous, and long names are not necessarily clear: process(the_current_thing_we_are_processing_right_now) is no less ambiguous or any more clear than: process(thing) In a well-written function that isn't too long, we ought to be able to find the definition of any local variable no more than half a page away. Local variables are usually far more limited in their scope and lifetime and the need for them to be self-documenting is correspondingly reduced. Insisting that *every* name must be meaningful *in isolation* is an over-reaction to poor quality code. Typically we read code in context: we can see the rest of the function and the definition of the variable is only a handful of lines away. The interpreter doesn't care what you call your variables, names are purely comments for the reader. It isn't true that the more comments the better, and the same applies to naming: - Just as comments can lie, so can names. I expect we've all read code where the names are actively misleading: mylist = {key: value} - Comments shouldn't simply repeat the obvious meaning of the code: x += 1 # add 1 to x and neither should variable names. If meaning can be inferred from the obvious meaning of the code, the need to spell out the meaning in full is reduced. (See my example above of number_of_pages.) - When writing comments we should eschew sesquipedalian loquaciousness x += 1 # increment the value of the variable x by the successor integer to the additive identity of Z and we ought to do the same for variable names. -- Steven From steve at pearwood.info Tue Feb 19 19:18:42 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 20 Feb 2019 11:18:42 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> Message-ID: <20190220001842.GI4465@ando.pearwood.info> On Wed, Feb 20, 2019 at 01:41:27AM +1100, Chris Angelico wrote: > page_count will usually be unambiguous. You might need total_pages to > mean "not the current section", thus leaving the shorter one available > for the narrower use. Obviously questions like this can't be answered > without context, but at an absolute minimum, "number_of" can almost > *always* be omitted. I disagree with that last bit. Of course we can replace "number_of" with its synonym "count", but we can't typically just omit it. Does "pages" mean the number of pages or the pages themselves? -- Steven From steve at pearwood.info Tue Feb 19 19:47:34 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Wed, 20 Feb 2019 11:47:34 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: <20190220004734.GJ4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 03:07:23PM +0100, simon.bordeyne wrote: > On top of that, it's not uncommon to > reach 6, even 7 indentation levels. All it takes is a loop in a loop > (looping through an array for instance), a condition and all of that > inside a class' method. Clearly that is not "all" it takes, since that's only *five* indents, not 6 or 7: class X: def method(self): for a in seq: for b in other: if cond: print("five indents") [...] > Just in that example, which is a very common > occurence, an doesn't warrant refactoring Doesn't it? Maybe it does, maybe it doesn't. It depends on what's going on inside the method. Maybe it should be written as a function (avoiding one indent). Maybe the row and column processing should be factored out into seperate methods: class X: def method(self): self.process_rows(seq) def process_rows(self, rows): for a in items: self.process_columns(a, other) def process_columns(self, a, cols): for b in cols: if cond: print("four indents") When this is possible, it has other advantages than merely saving one indent: we can test and document the row and column processing seperately, and reduce coupling between the components. (I can understand the column processing without caring about the row processing, and visa versa.) This is what I meant when I said that sometimes, the discipline required to keep to 79 columns helps give you better code. I started off wanting only to save an indent, but I got better documentation, better tests, and less coupled code that is easier to maintain. Of course sometimes you get *worse* code by refactoring. In which case you shouldn't do it :-) -- Steven From rosuav at gmail.com Tue Feb 19 20:09:12 2019 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 20 Feb 2019 12:09:12 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <20190220001842.GI4465@ando.pearwood.info> References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 11:19 AM Steven D'Aprano wrote: > > On Wed, Feb 20, 2019 at 01:41:27AM +1100, Chris Angelico wrote: > > > page_count will usually be unambiguous. You might need total_pages to > > mean "not the current section", thus leaving the shorter one available > > for the narrower use. Obviously questions like this can't be answered > > without context, but at an absolute minimum, "number_of" can almost > > *always* be omitted. > > I disagree with that last bit. > > Of course we can replace "number_of" with its synonym "count", but we > can't typically just omit it. Does "pages" mean the number of pages or > the pages themselves? > Fair point. However, in any context where "pages" could be a list of pages, you are unlikely to need a separate "pagecount", as it's just the length of the list. Maybe it's the number of pages you're _going_ to need, or something. But it's nearly impossible to judge without context. Maybe "almost always" was too strong, but in real-world contexts, I don't often need to specify that something is the "number of" something. ChrisA From turnbull.stephen.fw at u.tsukuba.ac.jp Tue Feb 19 22:10:16 2019 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Wed, 20 Feb 2019 12:10:16 +0900 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: Message-ID: <23660.50456.573148.141251@turnbull.sk.tsukuba.ac.jp> Brett Cannon writes: > On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote: > > I would be happy to have > > > > >>> [1,2,3].append(4)::sort()::max() +1 > > > > It makes things very easy to read: first create list, then append 4, > > then sort, then get the max. (Responding to the OP) In most cases, where one doesn't care about performance, one can rewrite as max(a := sorted([1, 2, 3] + [4])) + 1 This also tells you something about readability. I find the "dot-chaining" style easier to analyze than the nested function call style, because the methods are applied left-to-right and few inline operators are interpreted with right associativity -- note that this is a runtime decision! Where I don't care about analysis at this site, I define a function. If I do care about performance, writing it out line by line helps to emphasize that and to optimize well. I think given the current design with its long history, it would be more useful to identify pain points where functions like sorted() don't exist. > Also realize that design is on purpose so that mutating method > calls on lists do not return themselves to get the point across > that the mutation was in-place and not in fact a new list. I have come to think that this is suboptimal. Now I would like to experiment with a Python-like language where methods *always* return self, and where returning something else makes sense, Python-oid should provide a function that does that. Of course there would be an exception for dunders. It's not irritating enough to actually do this, though. :-) Steve From brett at python.org Tue Feb 19 22:49:37 2019 From: brett at python.org (Brett Cannon) Date: Tue, 19 Feb 2019 19:49:37 -0800 Subject: [Python-ideas] About PEP-582 In-Reply-To: References: Message-ID: On Tue, Feb 19, 2019 at 3:29 PM Philip Bergen via Python-ideas < python-ideas at python.org> wrote: > First attempt at this, so please be gentle. :) > I am very interested in the overall goal of not needing virtualenvs, but > I'm curious about the motivations behind pep-582. > In a word, simplicity. Teaching newcomers about virtual environments is a stumbling block, but so if when they accidentally pollute their global installation when they get started.PEP 582 is an attempt to handle the simple case nicely. > Could someone help me understand if this has previously been discussed and > in that case why it was decided against? > 1: Why only look in CWD and not traverse root-wise? > Surprise, potential security implications, other languages that have a similar solution don't do that. > 2: It feels to me like there is a larger story here about sprucing up > PYTHONPATH. > It's been a common theme that when people read PEP 582 they think there's a larger story, so you're not alone. :) > > About 2) I would prefer if we had a mechanism to automatically look for > .pythonpath.pth (or something with a better name, but to that effect). Then > we were not limited to a specific directory or location. This would > streamline cross project repos, for instance: you could have docker images > that came preloaded with common libraries and just add a layer with your > specifics in a different directory earlier in the paths specified by > .pythonpath.pth > > Using pip to install into your directories of choice is already supported, > although perhaps we should have some way of telling it to use the first > entry in .pythonpath.pth. > PEP 582 isn't about sharing installs, so I think your idea is orthogonal to its goals. -Brett > > I would be very grateful for some interaction on this. If there is general > interest I could submit some working code. > > Thanks, > // Phil > > -- > *Philip Bergen* > P: +1(415)200-7340 > *"Without data you are just another person with an opinion" -- W. Edwards > Deming* > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Tue Feb 19 23:56:42 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 20 Feb 2019 17:56:42 +1300 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: <5C6CDE0A.8080903@canterbury.ac.nz> Chris Angelico wrote: > if I'd been able to ascertain which functions were pure, or > at least side-effect-free, it would have saved me a lot of hassle.) I'm not sure how useful such annotations would be in practice, though. They're only as good as the diligence of the author in using them consistently and correctly, which makes them not much better than comments. -- Greg From ijkl at netc.fr Wed Feb 20 02:58:43 2019 From: ijkl at netc.fr (Jimmy Girardet) Date: Wed, 20 Feb 2019 08:58:43 +0100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <23660.50456.573148.141251@turnbull.sk.tsukuba.ac.jp> References: <23660.50456.573148.141251@turnbull.sk.tsukuba.ac.jp> Message-ID: <38da3c32-698b-e1a2-fd8c-61f109dbea88@netc.fr> Hi, thank for the replies. I searched on python-idea as Chris proposed me with "chain" and I've found 2 relevant discussions : * A? proposal from Cris Angelico ;-) https://mail.python.org/pipermail/python-ideas/2014-February/026079.html """Right. That's the main point behind this: it gives the *caller* the choice of whether to chain or not. That's really the whole benefit, right there.""" ChrisA the killer? answer of Nick Coghlan https://mail.python.org/pipermail/python-ideas/2014-February/026158.html explaining that the main point is about mutating and transforming : this is a part of Nick's answer : > start piece of answer Compare: ??? seq = get_data() ??? seq.sort() ??? seq = sorted(get_data()) Now, compare that with the proposed syntax as applied to the first operation: ??? seq = []->extend(get_data())->sort() That *looks* like it should be a data transformation pipeline, but it's not - each step in the chain is mutating the original object, rather than creating a new one. That's a critical *problem* with the idea, not a desirable feature. > end of answer It seems that in 2014 Guido was against chaining method. * Then in 2017 : https://mail.python.org/pipermail/python-ideas/2017-August/046770.html quite the same thing with a "rcompose" idea. So i understand that in this and previous discussions,? the main argument against it? was that mutation should looks like mutation? and not transformation (which returns value). This seems like a strong thing in core-dev mind since it's about design of the language. I totally agree with this idea of "mutating does not "return? value" but as a "user" of the language I easily can deal with the 2 ideas of "mutating does not return value" and "lets chain those things". I think you can do the last without breaking the first. "Although practicality beats purity" a : object::mutable1()::mutable2()::mutable3()::mutable4() b : multligne sequence mutable1(object) mutable2(object) mutable3(object) mutable4(object) Pros for a: ??? - stands in one line without loosing clarity. ??? - user are now used to play with "fluent" syntax in many libs or languages. Cons for a: ??? - b was here before :-) and fits the idioms of the language. ??? - a may look like you're using some `return Value` on mutating operation. I read somewhere that we are adult enough to be careful of what we are doing so, this cons is not obvious to me. At the very beginning of my thoughts I (maybe naively) thought that "a" could easily be converted to "b" at compile time but I'm not aware of those internal things. ? Le 20/02/2019 ? 04:10, Stephen J. Turnbull a ?crit?: > In most cases, where one doesn't care about performance, one can rewrite > as > > max(a := sorted([1, 2, 3] + [4])) + 1 Indeed, but at first glance, it's not obvious where? it starts and where it stops. [1,2,3].append(4)::List.sort()::max() +1?? gives you a sequential way of reading things like you talk or speak in every day life. > I think given the current design with its long history, it would be > more useful to identify pain points where functions like sorted() > don't exist. You're right on it. The str class is a? straightforward swiss army knife with methods you can chain. list or dict do not fit this idea. Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From benrudiak at gmail.com Wed Feb 20 05:08:07 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Wed, 20 Feb 2019 02:08:07 -0800 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: <20190219231247.GE4465@ando.pearwood.info> References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Tue, Feb 19, 2019 at 3:19 PM Steven D'Aprano wrote: > And I note that in Java, where the idea of checked exceptions > originated, it turned out to be full of problems and a very bad idea. What should be the default behavior of a language when the programmer doesn't explicitly handle an error? Options include: 1. Type error (Java, ML/Haskell) 2. Ignore it (C) 3. Pass it as-is to the caller 4. "Genericize" it, e.g. wrap it in a RuntimeError, then pass to the caller The problem with the Java approach is that people don't want to think about how to properly handle every error, and just wrap their code in catch (...) {} instead. I think it works much better in ML/Haskell, though perhaps only because the average skill level of the programmers is higher. The problem with the C approach is that people don't want to think about how to properly handle every error, and just call every function in a void context. The problem with passing exceptions as-is to the caller is that they're very often implementation details. If you're lucky, they will propagate to a generic catch-all somewhere which will generate a traceback that a human may be able to use to fix the problem. If you're unlucky, the caller wrote `return d[k].frobnicate()` inside a try block and frobnicate's internal KeyError gets misinterpreted as a lookup failure in d. That problem, of an inadvertently leaked implementation detail masquerading as a proper alternate return value, used to be a huge issue with StopIteration, causing bugs that were very hard to track down, until PEP 479 fixed it by translating StopIteration into RuntimeError when it crossed an abstraction boundary. I think converting exceptions to RuntimeErrors (keeping all original information, but bypassing catch blocks intended for specific exceptions) is the best option. (Well, second best after ML/Haskell.) But to make it work you probably need to support some sort of exception specification. I'm rambling. I suppose my points are: * Error handing is inherently hard, and all approaches do badly because it's hard and programmers hate it. * Stronger typing is only bad if you just want your code to run and are tired of fixing it to be type-correct. The people who voluntarily add type annotations to Python programs probably aren't those kinds of people; they're probably much more likely than the average programmer to want checked exceptions. * Declaring that a function only raises Foo doesn't have to mean "it raises Foo, and also passes exceptions from subfunctions to the caller unchanged, no matter what they are." It could also mean "it raises Foo, and converts other exceptions into RuntimeError." This would actually be useful because it would mean that you could safely put longer expressions in try blocks, instead of defensively just putting the one method call whose KeyError you want to handle in the try: block, and moving everything else to the else: block, as I tend to do all the time because I'm paranoid and I was bitten several times by that StopIteration problem. -- Ben From rosuav at gmail.com Wed Feb 20 05:42:17 2019 From: rosuav at gmail.com (Chris Angelico) Date: Wed, 20 Feb 2019 21:42:17 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 9:09 PM Ben Rudiak-Gould wrote: > That problem, of an inadvertently leaked implementation detail > masquerading as a proper alternate return value, used to be a huge > issue with StopIteration, causing bugs that were very hard to track > down, until PEP 479 fixed it by translating StopIteration into > RuntimeError when it crossed an abstraction boundary. That's because a generator function conceptually has three ways to provide data (yield, return, and raise), but mechanically, one of them is implemented over the other ("return" is "raise StopIteration with a value"). For other raised exceptions, this isn't a problem. > I think converting exceptions to RuntimeErrors (keeping all original > information, but bypassing catch blocks intended for specific > exceptions) is the best option. (Well, second best after ML/Haskell.) > But to make it work you probably need to support some sort of > exception specification. The trouble with that is that it makes refactoring very hard. You can't create a helper function without knowing exactly what it might be raising. > I'm rambling. I suppose my points are: > > * Error handing is inherently hard, and all approaches do badly > because it's hard and programmers hate it. Well, yeah, no kidding. :) > ... I was bitten several times by > that StopIteration problem. > There's often a completely different approach that doesn't leak StopIteration. One of my workmates started seeing RuntimeErrors, and figured he'd need a try/except in this code: def _generator(self, left, right): while True: yield self.operator(next(left), next(right)) But instead of messing with try/except, it's much simpler to use something else - in this case, zip. Generally, it's better to keep things simple rather than to complicate them with new boundaries. Unless there's a good reason to prevent leakage, I would just let exception handling do whatever it wants to. But if you want to specifically say "this function will not raise anything other than these specific exceptions", that can be done with a decorator: def raises(*exc): """Declare and enforce what a function will raise The decorated function will not raise any Exception other than the specified ones, or RuntimeError. """ def deco(func): @functools.wraps(func) def convert_exc(*a, **kw): try: return func(*a, **kw) except exc: raise except Exception as e: raise RuntimeError from e convert_exc.may_raise = exc # in case it's wanted return convert_exc return deco This way, undecorated functions behave as normal, so refactoring isn't impacted. But if you want the help of a declared list of exceptions, you can have it. @raises(ValueError, IndexError) def frob(x): ... ChrisA From j.orponen at 4teamwork.ch Wed Feb 20 06:08:48 2019 From: j.orponen at 4teamwork.ch (Joni Orponen) Date: Wed, 20 Feb 2019 12:08:48 +0100 Subject: [Python-ideas] About PEP-582 In-Reply-To: References: Message-ID: On Wed, Feb 20, 2019 at 4:49 AM Brett Cannon wrote: > On Tue, Feb 19, 2019 at 3:29 PM Philip Bergen via Python-ideas < > python-ideas at python.org> wrote: > >> First attempt at this, so please be gentle. :) >> I am very interested in the overall goal of not needing virtualenvs, but >> I'm curious about the motivations behind pep-582. >> > > In a word, simplicity. Teaching newcomers about virtual environments is a > stumbling block, but so if when they accidentally pollute their global > installation when they get started.PEP 582 is an attempt to handle the > simple case nicely. > Is Buildout forgotten? It's not dead and achieves the same in this regard. It works by flushing out meaningfully-shebanged wrapper scripts with exactly injected sys.path. http://docs.buildout.org/en/latest/ -- Joni Orponen -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2QdxY4RzWzUUiLuE at potatochowder.com Wed Feb 20 09:14:33 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Wed, 20 Feb 2019 08:14:33 -0600 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <38da3c32-698b-e1a2-fd8c-61f109dbea88@netc.fr> References: <23660.50456.573148.141251@turnbull.sk.tsukuba.ac.jp> <38da3c32-698b-e1a2-fd8c-61f109dbea88@netc.fr> Message-ID: On 2/20/19 1:58 AM, Jimmy Girardet wrote: > You're right on it. The str class is a? straightforward swiss army knife > with methods you can chain. list or dict do not fit this idea. Python strings are immutable. Python lists and dicts are not. Both classes are straightforward. From steve at pearwood.info Wed Feb 20 10:10:29 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 21 Feb 2019 02:10:29 +1100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: Message-ID: <20190220151028.GK4465@ando.pearwood.info> On Tue, Feb 19, 2019 at 01:52:34PM -0800, Brett Cannon wrote: > On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote: [...] > > I would be happy to have > > > > >>> [1,2,3].append(4)::sort()::max() +1 > > > > It makes things very easy to read: first create list, then append 4, > > then sort, then get the max. > > > > Easy for you, but not necessarily everyone else. For instance, I find the > explicit writing out of the lines easier. That's possibly a matter of familiarity. I'd be very surprised if you preferred this: mystr = mystr.strip() mystr = mystr.expandtabs() mystr = mystr.lower() mystr = mystr.replace('ham', 'spam') result = function(mystr) over this fluent version: result = function(mystr.strip().expandtabs().lower().replace('ham', 'spam')) Or if you're worried about the line length: result = function(mystr.strip() .expandtabs() .lower() .replace('ham', 'spam') ) works for me. -- Steven From 2QdxY4RzWzUUiLuE at potatochowder.com Wed Feb 20 11:33:25 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Wed, 20 Feb 2019 10:33:25 -0600 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <20190220151028.GK4465@ando.pearwood.info> References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: On 2/20/19 9:10 AM, Steven D'Aprano wrote: > That's possibly a matter of familiarity. I'd be very surprised if you > preferred this: > > mystr = mystr.strip() > mystr = mystr.expandtabs() > mystr = mystr.lower() > mystr = mystr.replace('ham', 'spam') > result = function(mystr) > > over this fluent version: > > result = function(mystr.strip().expandtabs().lower().replace('ham', 'spam')) Those two blocks of code don't quite do the same thing. What is the value of mystr at the end of each block? Yes, as a matter of fact, I do think that that's the important question. Consider these two similar blocks of code: f(mylist): mylist.sort() mylist.pop() mylist.reverse() g(mystr): return mystr.strip().expandtabs().replace('ham', 'spam') The difference is more than a matter of which syntax I prefer, the difference is a matter of how I build software. Python lists and dicts are classic objects. I don't interact with the underlying data, I send the object a request to operate on that data, and rest assured that the object is doing the right thing. I can create one at the top of my application, pass it around, make a series of request against it, and ask that very same object for the end result: some_list = get_some_data() f(some_list) print(some_list) # what happened to my original? Python strings, however, don't work that way. If I create one at the top of my application, I can pass it around, but my original remains as is. some_string = get_some_data() another_string = g(some_string) # why do I need a new string? print(some_string) print(another_string) It's a different way of doing things. Please don't conflate them. > Or if you're worried about the line length: > > result = function(mystr.strip() > .expandtabs() > .lower() > .replace('ham', 'spam') > ) > > works for me. I am no longer impressed that you squeezed the original into exactly 80 columns. ;-) From bruce at leban.us Wed Feb 20 13:24:25 2019 From: bruce at leban.us (Bruce Leban) Date: Wed, 20 Feb 2019 10:24:25 -0800 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: Here's a syntax that solves this using the new operators _:= and ,_ a = [1,2,3] ( _:= a ,_ .append(4) ,_ .sort() ) Personally, I find this a bit harder to read on one line and would break it up like this: (_:= a ,_ .append(4) ,_ . .sort() ) --- Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfine2358 at gmail.com Wed Feb 20 13:31:07 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Wed, 20 Feb 2019 18:31:07 +0000 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: There's a problem with introducing ,_ as a new operator. $ python3.6 Python 3.6.2 (default, Jul 29 2017, 00:00:00) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 2 + 2 4 >>> 4 ,_ + 6 (4, 10) Hint: >>> _ (4, 10) >>> 3 ,_ (3, (4, 10)) -- Jonathan From bruce at leban.us Wed Feb 20 13:40:32 2019 From: bruce at leban.us (Bruce Leban) Date: Wed, 20 Feb 2019 10:40:32 -0800 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 10:34 AM Jonathan Fine wrote: > There's a problem with introducing ,_ as a new operator. > I should have put "new" in scare quotes to be more clear as it's not really new. As you've observed this is already implemented. For it to work as in my example you also need to use the "new" _:= operator which requires Python 3.8. --- Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfine2358 at gmail.com Wed Feb 20 13:52:40 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Wed, 20 Feb 2019 18:52:40 +0000 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: I think this >>> a = [1,2,3] >>> _ = a >>> ( _ .append(4), _ .sort() ) (None, None) is clearer than a = [1,2,3] ( _:= a ,_ .append(4) ,_ .sort() ) And it works in every version of Python3 (and Python2 I expect). -- Jonathan From rhodri at kynesim.co.uk Wed Feb 20 14:02:38 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Wed, 20 Feb 2019 19:02:38 +0000 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: <0258a265-e13e-8b9a-0484-d95f7966f3de@kynesim.co.uk> On 20/02/2019 18:24, Bruce Leban wrote: > Here's a syntax that solves this using the new operators _:= and ,_ > > > a = [1,2,3] > ( _:= a ,_ .append(4) ,_ .sort() ) I'm not sure what problem you are solving here, but if that's the solution I'd rather have the problem. There is absolutely nothing in that syntax that suggests what's going on. -- Rhodri James *-* Kynesim Ltd From bruce at leban.us Wed Feb 20 14:15:51 2019 From: bruce at leban.us (Bruce Leban) Date: Wed, 20 Feb 2019 11:15:51 -0800 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <0258a265-e13e-8b9a-0484-d95f7966f3de@kynesim.co.uk> References: <20190220151028.GK4465@ando.pearwood.info> <0258a265-e13e-8b9a-0484-d95f7966f3de@kynesim.co.uk> Message-ID: On Wed, Feb 20, 2019 at 11:03 AM Rhodri James wrote: > On 20/02/2019 18:24, Bruce Leban wrote: > > a = [1,2,3] > > ( _:= a ,_ .append(4) ,_ .sort() ) > > I'm not sure what problem you are solving here, but if that's the > solution I'd rather have the problem. There is absolutely nothing in > that syntax that suggests what's going on. > > Given the responses, I think I was a bug more obtuse than necessary. My apologies. This is already in Python 3.8. I am NOT actually suggesting a change to the language. I'm showing how to "solve" the "problem" of wanting to write chained method calls on a single line. I agree the solution is unreadable and worse than the problem. Any other proposed solution is merely bikeshedding the syntax and I think suffers from the same non-readability problem. For example these are essentially the same: _:= a ,_. append(4) ,_. sort() a :: append(4) :: sort() --- Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfine2358 at gmail.com Wed Feb 20 14:45:10 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Wed, 20 Feb 2019 19:45:10 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: I wrote: def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dict[str, AnyType], module_name: Optional[str], ) -> Dict[str, AnyType]: pass Samuel Colvin then told us that his example was already formatted with black.py, using a long line length. Here's a suggestion, at least for people projects that use black.py (such as Samuel's). It is to use black.py with a line-length of say 80 characters for code that is saved in version control. And when editing code, use whatever line-length that happens to suit the tools you are using. Indeed, like a word-processor, one could use black.py to 'line-wrap' the Python code to what is the current width of the editor window. Indeed, this might be a useful feature in Jupyter - see https://github.com/drillan/jupyter-black. And I've created https://github.com/drillan/jupyter-black/issues/3 Perhaps set the black line length to the width of the text box -- Jonathan From jfine2358 at gmail.com Wed Feb 20 14:53:21 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Wed, 20 Feb 2019 19:53:21 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <20190219232914.GG4465@ando.pearwood.info> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <20190219232914.GG4465@ando.pearwood.info> Message-ID: Steven D'Aprano wrote: > > I wasn't making a point. I was providing evidence. > > Evidence of what? > > What was the point of this evidence? > > If it was to demonstrate that it is possible to reformat function > parameter lists to split over multiple lines, we already knew that. > > If it was to demonstrate something else, I have no idea what. One idea arising from the evidence I provided was that like a word-processor, one could use black.py to 'line-wrap' the Python code to what is the current width of the editor window. Which may vary from person to person. (I did not say it at the time, because I did not have it at the time. And because others might have different useful ideas coming from the same piece of evidence.) See https://mail.python.org/pipermail/python-ideas/2019-February/055424.html -- Jonathan From rosuav at gmail.com Wed Feb 20 14:57:20 2019 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 21 Feb 2019 06:57:20 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine wrote: > Here's a suggestion, at least for people projects that use black.py > (such as Samuel's). It is to use black.py with a line-length of say 80 > characters for code that is saved in version control. And when editing > code, use whatever line-length that happens to suit the tools you are > using. > > Indeed, like a word-processor, one could use black.py to 'line-wrap' > the Python code to what is the current width of the editor window. >From my experience (granted, I work heavily with students, so maybe it's different if everyone involved in the project has 5+ or 10+ years coding), autoformatters are a blight. They take a simple, easy-to-find missed parenthesis, and completely obscure it by reindenting the code until it finds something unrelated that seems to close it. The indentation in the code of even a novice programmer is valuable information about *programmer intent*, and throwing that away automatically as part of checking in code (or, worse, every time you save the file) is a bad idea. Easy bugs become hard. Of course, if you assume that everything in your code is perfect, then by all means, reformat it however you like. If you're 100% confident that nobody writes any buggy code, then the formatting doesn't matter, and you can display it in whichever way looks prettiest. But if you appreciate ways of discovering bugs more easily, preserve everything that represents the programmer's intention. ChrisA From pflarr at gmail.com Wed Feb 20 17:51:15 2019 From: pflarr at gmail.com (Paul Ferrell) Date: Wed, 20 Feb 2019 15:51:15 -0700 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: Opinion first - I don't see a need to change PEP 8. I recommend 100 char width for Python, which is acceptable under PEP 8 anyway. I think the real limit should be around 70 characters per line, not including leading white-space, but I realize that's impractical. I work mostly at 100 character line width, and the question of line width came up for me recently. Otherwise, I follow PEP 8. I want to see where, and why I exceed 79 chars, so I dove into a decently sized module file of mine and tallied the results. This is what I found. 563 total lines 448 non-blank lines For the non-blank lines: 49.6 characters per line on average 36.7 non-leading-whitespace characters per line 13.1 leading spaces per line on average 15.5% of lines exceeded 79 chars. The 69 lines that exceeded 79 characters fell into the following categories, listed according to how annoying they would be to fix. 1 - with statements I have a with statement that contains two context managers "with open(blah) as b, open(foo) as f:". There isn't a really good way to wrap this without adding another with statement or a backslash. 3 - function calls Function calls, even with the arguments put one per line, often exceed 80 (and sometimes 100) character limit. The issue tends to be a combination of tabbing, kwarg names, and the context in which all of this is used. It's often unavoidable. variable = some_class.method(argument=value, argument2=value) 5 - Overly deep logic There were a couple of blocks of code that should have been pushed into separate methods/functions. I do occasionally run into issues where there simply isn't room (in 79 chars) for the logic required, and that logic can't reasonably be separated out. 8 - Format calls While I love the new format syntax, I almost always end up moving the format call to a new line with 4 spaces of extra indentation. These were instances of when I didn't. 21 - Comments There's plenty of space for readable comments in most cases. Under several nested scopes, however, the space gets pretty tight. Those extra 20 chars go a long way. 12 - Strings Like comments, having a few extra chars for strings (mostly exception messages in this case) goes a long way when even moderately nested. 2 - Chained conditionals if A and B and C Should have been: if (A and B and C): 16 - Doc strings These are easily fixable with no change in readability, and rarely have issues with padding. On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico wrote: > On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine wrote: > > Here's a suggestion, at least for people projects that use black.py > > (such as Samuel's). It is to use black.py with a line-length of say 80 > > characters for code that is saved in version control. And when editing > > code, use whatever line-length that happens to suit the tools you are > > using. > > > > Indeed, like a word-processor, one could use black.py to 'line-wrap' > > the Python code to what is the current width of the editor window. > > From my experience (granted, I work heavily with students, so maybe > it's different if everyone involved in the project has 5+ or 10+ years > coding), autoformatters are a blight. They take a simple, easy-to-find > missed parenthesis, and completely obscure it by reindenting the code > until it finds something unrelated that seems to close it. The > indentation in the code of even a novice programmer is valuable > information about *programmer intent*, and throwing that away > automatically as part of checking in code (or, worse, every time you > save the file) is a bad idea. Easy bugs become hard. > > Of course, if you assume that everything in your code is perfect, then > by all means, reformat it however you like. If you're 100% confident > that nobody writes any buggy code, then the formatting doesn't matter, > and you can display it in whichever way looks prettiest. But if you > appreciate ways of discovering bugs more easily, preserve everything > that represents the programmer's intention. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Paul Ferrell pflarr at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Wed Feb 20 18:34:24 2019 From: abedillon at gmail.com (Abe Dillon) Date: Wed, 20 Feb 2019 17:34:24 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: [Samuel Colvin] > > I don't see how anyone can say that would be more readable with a 80 > character line limit. For starters, type annotations don't add anything that good documentation would have required before. In most docstring style guides that I know of, the arguments list is supposed to be at least one line per argument, so really it should look like so: def resolve_annotations(raw_annotations, module_name): """ description of what the function does Arguments: raw_annotations (type annotation): description of raw_annotations module_name (type annotation): description of module name Returns (type annotation): description or return value """ Which can easily be replaced with: def resolve_annotations( raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: """ description of what the module does Arguments: raw_annotations: description of raw_annotations module_name: description of module name Returns: description or return value """ Often, I find, people make add a lot of redundant noise to names which is either clear from context like; math.log, not math.mathematical_log_function, or doesn't add anything like; user_data instead of user, or job_info instead of job, or raw_annotations instead of annotations. It's often just as good to write: def resolve(annotations: Dict[str, Type[Any]], module: Optional[str]) -> Dict[str, Type[Any]]: """...""" On Tue, Feb 19, 2019 at 8:30 AM Samuel Colvin wrote: > I too would argue that it's time to reconsider line length limits. > > But the reason is not monitor changes, or any particularly strong personal > opinion, but changes to python: > > Let's take a real life example from here > (changed > very slightly for this example), in tranitional python the signature might > be: > > def resolve_annotations(raw_annotations, module_name): > > 55 characters, all fine. Now let's look at that same function in modern > python with type hints: > > def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], > module_name: Optional[str]) -> Dict[str, Type[Any]]: > > 119 characters! No daft 5-word variable names, just a clean (if strict) > function definition. I don't see how anyone can say that would be more > readable with a 80 character line limit. And that's not even an extreme > case, we don't have lots of "Optional[..]" or "Tuple[ThingA, ThingB, > ThingC]". > > Type hints (for good or bad depending on your view point) have made python > code more verbose, that's just a fact. Code that used to fit on one line > with 80char limit now require 120 (or more), therefore in my opinion the > recommendation should change to keep up with changes in python. > > My preference is 120 characters (that's also the default in pycharm I > believe). It works well on a desktop monitor, leaving room for a file > browser and part of another window, it's also fine on a 13" laptop screen. > > Then again, every IDE and linter I've used (even black) allows the line > length to be varried, so this is only really a problem in the standard > library and libraries which adhere closely to pep8. > > Samuel > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Wed Feb 20 18:43:06 2019 From: abedillon at gmail.com (Abe Dillon) Date: Wed, 20 Feb 2019 17:43:06 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: Thankfully, style guidelines are based upon the limitations of humans like the size of the fovea and the general ability for people to follow long lines, NOT on the limitations of tools like grep. On Tue, Feb 19, 2019 at 10:29 AM Anders Hovm?ller wrote: > > If it were me, I'd probably write (or would have re-written when I added > the type hints) that as follows: > > def resolve_annotations( > *, > raw_annotations: Dict[str, Type[Any]], > module_name: Optional[str] > ) -> Dict[str, Type[Any]]: > > > I would like to point out here that breaking up a line breaks grepping > quite badly. I've had to write AST-based searches to find simple usages of > arguments in the code base at work precisely because of code that is split > on likes like this. (This tool is available here: > https://github.com/boxed/parso_utils) > > I would vastly prefer a soft like break algorithm that formatted the code > as per your examples and having the code on disk be single line no matter > what. > > In proprietary projects where one can agree on the tools used for the code > this can be quite doable, but I agree it's not great for open source > projects. > > / Anders > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abedillon at gmail.com Wed Feb 20 19:08:32 2019 From: abedillon at gmail.com (Abe Dillon) Date: Wed, 20 Feb 2019 18:08:32 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: [simon.bordeyne] > I find that 100 to 120 characters is ideal as far as line length goes. Your finding goes against a long history of people attempting to present text in the most readable way possible. AFIK, the human fovea hasn't grown much larger in recent years. [simon.bordeyne] > On top of that, it's not uncommon to reach 6, even 7 indentation levels. It should be pretty uncommon. You might want to re-think your coding style if you're regularly writing code that's so deeply indented. A good trick is to use helper functions: #instead of this if condition: ...code #do this if condition: handle_it() [simon.bordeyne] > All it takes is a loop in a loop (looping through an array for instance), > a condition and all of that inside a class' method. Just in that example, > which is a very common occurence, an doesn't warrant refactoring, there is > 5 indentation level, eg a quarter of the recommended line length. You should check out the itertools library and possibly the toolz package. I find it's often pretty simple to collapse nested loops in python: for n, element in enumerate(chain(*array)): r, c = divmod(n, len(array[0])) # if you need the indexes if condition(element): do_something(element) # this follows the one-line one-thought rule over PEP8 On Tue, Feb 19, 2019 at 8:08 AM simon.bordeyne wrote: > I find that 100 to 120 characters is ideal as far as line length goes. In > my opinion, splitting lines is much worse in terms of cognitive burden than > just a longer line. On top of that, it's not uncommon to reach 6, even 7 > indentation levels. All it takes is a loop in a loop (looping through an > array for instance), a condition and all of that inside a class' method. > Just in that example, which is a very common occurence, an doesn't warrant > refactoring, there is 5 indentation level, eg a quarter of the recommended > line length. > > Defining decorators also goes up there in terms of number of indents by > the way. > > As far as monitor size goes, I agree that on a laptop is not ideal for > 100+ characters per line if you want two pieces of code side by side. And, > fyi, I work on a 23" monitor at home and on a 15.6" monitor on the go. Both > are perfectly fine with 100 characters a line. > > A good middle ground would be to enforce customization of that rule in the > most used python linters. A simple setting to set the number of characters > before a linting warning occurs would be acceptable. > > > > Envoy? depuis mon smartphone Samsung Galaxy. > > -------- Message d'origine -------- > De : David Mertz > Date : 19/02/2019 07:28 (GMT+01:00) > ? : Anders Hovm?ller > Cc : Simon , python-ideas < > python-ideas at python.org> > Objet : Re: [Python-ideas] PEP 8 update on line length > > 60, or 68, or 80 characters, is not per se a cognitive limit. Yes, sure > whitespace counts much less towards that burden than do regular characters. > And to a significant degrees, punctuation vs. letters vs. numbers matter. > And sure familiar words such as keywords scan a bit easier than unfamiliar > names of variables. And so on. > > But 80 characters in general is already too wide most of the time. 65 is a > better goal as a rule of thumb, with 80 already being for exceptionally > long lines. Python keywords are already short, there's not much improvement > to be had there. Saving two characters for acryptic WHL isn't better than > the word 'while', for example. > > Pretty much the only time my code how's more than 80 characters is when it > includes string literally that occupy a large chunk of the width. But if > that 50 character string is the last argument of a function call, the > reader can mostly stop scanning at it's beginning, so it's not terrible. > When I have many keyword arguments, I break them into multiple physical > lines using parents too continue the logical line. Or if I have complex > compound conditions, I give the subclauses short but descriptive names > before the if/elif. > > On Tue, Feb 19, 2019, 1:11 AM Anders Hovm?ller >> >> >> > On 19 Feb 2019, at 05:48, David Mertz wrote: >> > >> > You either have much better eyes to read tiny fonts than I do, or maybe >> a much larger monitor (it's hard for me to fit a 30"" monitor in my laptop >> bag). >> > >> > But that's not even the real issue. If the characters were in giant >> letters on billboards, I still would never want more than 80 of them on a >> line (well, rarely, I violate PEP 8 sometimes). Centuries if not millennia >> of experience with writing show that cognitive burden goes up >> exponentially, not linearly, as lines get to be more than about 60 >> characters. >> >> If that is the issue then we should be talking about non-space >> characters, not a 68 column limit right? No way does 40 spaces due to >> indent count towards the cognitive burden :) >> >> Also, if the cognitive burden is the issue then we should talk about >> short forms for keyword arguments again. The way the 68 column limit works >> in practice is that people avoid keyword arguments because of line length, >> plus the issues already mentioned. >> >> / Anders > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Wed Feb 20 19:21:53 2019 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 21 Feb 2019 11:21:53 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon wrote: > > [simon.bordeyne] >> >> I find that 100 to 120 characters is ideal as far as line length goes. > > Your finding goes against a long history of people attempting to present text in the most readable way possible. > AFIK, the human fovea hasn't grown much larger in recent years. You can't see the entire line in focus simultaneously anyway, so the line length is about how far you can flit your eye left to right, not the actual fovea itself. > [simon.bordeyne] >> >> On top of that, it's not uncommon to reach 6, even 7 indentation levels. > > It should be pretty uncommon. You might want to re-think your coding style if you're regularly writing code that's so deeply indented. > A good trick is to use helper functions: > > #instead of this > if condition: > ...code > > #do this > if condition: > handle_it() And this is always cited as the "obvious" solution. The trouble is, unless "handle_it" has a name that tells you EVERYTHING about what it does, you probably will end up having to go look at its definition - which means a lot more flicking around. The cost of a long line has to be balanced against the cost of *avoiding* having a long line. Splitting a line into consecutive lines has less cost than breaking it out into a function, *unless* the function truly has its own meaning. ChrisA From abedillon at gmail.com Wed Feb 20 19:27:36 2019 From: abedillon at gmail.com (Abe Dillon) Date: Wed, 20 Feb 2019 18:27:36 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: First of all, thank you so much for taking the time to do some actual analysis! I only have one thing to add: [Paul Ferrell] > 3 - function calls > Function calls, even with the arguments put one per line, often exceed 80 > (and sometimes 100) character limit. The issue tends to be a combination of > tabbing, kwarg names, and the context in which all of this is used. It's > often unavoidable. > variable = some_class.method(argument=value, > argument2=value) This reminds me of a bit that shows up often in Kevlin Henney's talks . A better way to list arguments is only one indentation level above the current: variable = some_class.method( argument=value, argument2=value) Trying to match the indentation of the opening line is less readable and less robust to refactoring: variable = some_class.method(argument=value, argument2=value) var = cls.method(argument=value, argument2=value) On Wed, Feb 20, 2019 at 4:52 PM Paul Ferrell wrote: > Opinion first - I don't see a need to change PEP 8. I recommend 100 char > width for Python, which is acceptable under PEP 8 anyway. I think the real > limit should be around 70 characters per line, not including leading > white-space, but I realize that's impractical. > > I work mostly at 100 character line width, and the question of line width > came up for me recently. Otherwise, I follow PEP 8. I want to see where, > and why I exceed 79 chars, so I dove into a decently sized module file of > mine and tallied the results. This is what I found. > > 563 total lines > 448 non-blank lines > > For the non-blank lines: > 49.6 characters per line on average > 36.7 non-leading-whitespace characters per line > 13.1 leading spaces per line on average > 15.5% of lines exceeded 79 chars. > > The 69 lines that exceeded 79 characters fell into the following > categories, listed according to how annoying they would be to fix. > > 1 - with statements > I have a with statement that contains two context managers "with > open(blah) as b, open(foo) as f:". There isn't a really good way to wrap > this without adding another with statement or a backslash. > > 3 - function calls > Function calls, even with the arguments put one per line, often exceed 80 > (and sometimes 100) character limit. The issue tends to be a combination of > tabbing, kwarg names, and the context in which all of this is used. It's > often unavoidable. > variable = some_class.method(argument=value, > argument2=value) > > 5 - Overly deep logic > There were a couple of blocks of code that should have been pushed into > separate methods/functions. I do occasionally run into issues where there > simply isn't room (in 79 chars) for the logic required, and that logic > can't reasonably be separated out. > > 8 - Format calls > While I love the new format syntax, I almost always end up moving the > format call to a new line with 4 spaces of extra indentation. These were > instances of when I didn't. > > 21 - Comments > There's plenty of space for readable comments in most cases. Under several > nested scopes, however, the space gets pretty tight. Those extra 20 chars > go a long way. > > 12 - Strings > Like comments, having a few extra chars for strings (mostly exception > messages in this case) goes a long way when even moderately nested. > > 2 - Chained conditionals > if A and B and C > Should have been: > if (A and > B and > C): > > 16 - Doc strings > These are easily fixable with no change in readability, and rarely have > issues with padding. > > On Wed, Feb 20, 2019 at 12:57 PM Chris Angelico wrote: > >> On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine >> wrote: >> > Here's a suggestion, at least for people projects that use black.py >> > (such as Samuel's). It is to use black.py with a line-length of say 80 >> > characters for code that is saved in version control. And when editing >> > code, use whatever line-length that happens to suit the tools you are >> > using. >> > >> > Indeed, like a word-processor, one could use black.py to 'line-wrap' >> > the Python code to what is the current width of the editor window. >> >> From my experience (granted, I work heavily with students, so maybe >> it's different if everyone involved in the project has 5+ or 10+ years >> coding), autoformatters are a blight. They take a simple, easy-to-find >> missed parenthesis, and completely obscure it by reindenting the code >> until it finds something unrelated that seems to close it. The >> indentation in the code of even a novice programmer is valuable >> information about *programmer intent*, and throwing that away >> automatically as part of checking in code (or, worse, every time you >> save the file) is a bad idea. Easy bugs become hard. >> >> Of course, if you assume that everything in your code is perfect, then >> by all means, reformat it however you like. If you're 100% confident >> that nobody writes any buggy code, then the formatting doesn't matter, >> and you can display it in whichever way looks prettiest. But if you >> appreciate ways of discovering bugs more easily, preserve everything >> that represents the programmer's intention. >> >> ChrisA >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Paul Ferrell > pflarr at gmail.com > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Wed Feb 20 20:21:47 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 21 Feb 2019 12:21:47 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> <20190219232914.GG4465@ando.pearwood.info> Message-ID: <20190221012147.GL4465@ando.pearwood.info> On Wed, Feb 20, 2019 at 07:53:21PM +0000, Jonathan Fine wrote: > Steven D'Aprano wrote: > > > > I wasn't making a point. I was providing evidence. > > > > Evidence of what? > > > > What was the point of this evidence? > > > > If it was to demonstrate that it is possible to reformat function > > parameter lists to split over multiple lines, we already knew that. > > > > If it was to demonstrate something else, I have no idea what. > > One idea arising from the evidence I provided Evidence for what? > was that like a > word-processor, one could use black.py to 'line-wrap' the Python code > to what is the current width of the editor window. Which may vary from > person to person. So when I receive a bug report with a traceback, the line number and line of code showing in the traceback may have little or no relationship to those on disk or in my editor? -- Steven From abedillon at gmail.com Wed Feb 20 20:26:39 2019 From: abedillon at gmail.com (Abe Dillon) Date: Wed, 20 Feb 2019 19:26:39 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: [Chris Angelico] > > And this is always cited as the "obvious" solution. Yes. I think simon even referred to this "obvious" solution in his post when he said, "...which is a very common ocurence, *and doesn't warrant refactoring*" So, my comment may have been unwarranted. [Chris Angelico] > The trouble is, unless "handle_it" has a name that tells you EVERYTHING > about what it > does, you probably will end up having to go look at its definition - > which means a lot more flicking around. I think you're over emphasizing "EVERYTHING" and "probably". If your de-bugging or refactoring, You typically have enough context to make an educated guess if you need to look deeper. The Wikipedia for the game Tic-Tac-Toe (AKA Nots and Crosses) describes a strategy play(board, my_mark): # Win moves = win(board, my_mark) if moves: return random.choice(moves) # Block moves = win(board, opposite(my_mark)) if moves: return random.choice(moves) # Fork moves = fork(board, my_mark) if moves: return random.choice(moves) # Block Fork moves = fork(board, opposite(my_mark)) if moves: return block_fork(moves, board, my_piece) # Center if board[1][1] is None: return (1, 1) # Corners moves = empty_corners(board) if moves: return random.choice(moves) # Sides moves = empty_sides(board) if moves: return random.choice(moves) # Failing test board = [['O' , None, None] ['X' , 'X' , None] [None, None, None]] mark = 'O' result = play(board, mark) expected = (1, 2) assert move == expected, f"Block! Expected: {expected}, Got: {result}" You don't need to know EVERYTHING about how block_fork works to debug that failure. You probably don't need to know EVERYTHING about how random.choice works either. You don't need to know about how most of the functions in the code work. The code is not blocking an opponent's win. The fault must be in "win" or "opposite". [Chris Angelico] > The cost of a long line has to be balanced against the cost of *avoiding* > having a long line. Splitting a line into consecutive lines has less cost > than > breaking it out into a function, *unless* the function truly has its own > meaning. That's a good point. Pragmatism should always win the day, of course; and excessive functional decomposition can cause it's own readability issues. I only offer it as a strategy, not a flawless solution. Sometimes going beyond 80 columns is the most pragmatic choice, but such cases should be rare. On Wed, Feb 20, 2019 at 6:23 PM Chris Angelico wrote: > On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon wrote: > > > > [simon.bordeyne] > >> > >> I find that 100 to 120 characters is ideal as far as line length goes. > > > > Your finding goes against a long history of people attempting to present > text in the most readable way possible. > > AFIK, the human fovea hasn't grown much larger in recent years. > > You can't see the entire line in focus simultaneously anyway, so the > line length is about how far you can flit your eye left to right, not > the actual fovea itself. > > > [simon.bordeyne] > >> > >> On top of that, it's not uncommon to reach 6, even 7 indentation > levels. > > > > It should be pretty uncommon. You might want to re-think your coding > style if you're regularly writing code that's so deeply indented. > > A good trick is to use helper functions: > > > > #instead of this > > if condition: > > ...code > > > > #do this > > if condition: > > handle_it() > > And this is always cited as the "obvious" solution. The trouble is, > unless "handle_it" has a name that tells you EVERYTHING about what it > does, you probably will end up having to go look at its definition - > which means a lot more flicking around. The cost of a long line has to > be balanced against the cost of *avoiding* having a long line. > Splitting a line into consecutive lines has less cost than breaking it > out into a function, *unless* the function truly has its own meaning. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Wed Feb 20 20:30:32 2019 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 21 Feb 2019 12:30:32 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: On Thu, Feb 21, 2019 at 12:26 PM Abe Dillon wrote: > You don't need to know EVERYTHING about how block_fork works to debug that failure. You > probably don't need to know EVERYTHING about how random.choice works either. You don't > need to know about how most of the functions in the code work. The code is not blocking an > opponent's win. The fault must be in "win" or "opposite". Not about HOW it works. That's irrelevant. You DO need to know about what it does, which is what I said. In the case of random.choice, that's very clearly defined by its documentation: it chooses a random element from the thing you give it. If you don't know that, you have to look it up to determine whether that's the problem. ChrisA From pythonchb at gmail.com Wed Feb 20 20:46:13 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Wed, 20 Feb 2019 17:46:13 -0800 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: TL;DR: When talking about all this, there are two distictions that should be considered: mutating operations vs copying operations functions vs methods. This has a lot of impact on the design, and it's very important that any final syntax makes these distinctions clear. On Wed, Feb 20, 2019 at 8:33 AM Dan Sommers < 2QdxY4RzWzUUiLuE at potatochowder.com> wrote: > Python lists and dicts are classic objects. I don't interact with the > underlying data, > Python strings, however, don't work that way. If I create one at the > top of my application, I can pass it around, but my original remains as > is. > It's a different way of doing things. Please don't conflate them. > however, that's kind of what this thread is all about :-) Python has two "kinds" of objects -- mutable and immutable. Immutable objects necessarily return new objects when you call methods on them (or do something else entirely) This also makes them naturally easy to chain operations, as per the string processing example(s). However, mutating operations are not so easy to chain -- you can't write: a_list.append(item).sort()[:10] To, say, add a value to a list and get th first ten items in sorted order I think the solution to THAT is to do as someone suggested, and to identify the missing non-mutating operations. after all, we can, with lists, do: sorted(a_list + [item])[:10] but there are multiple issues with that: 1) a mixture of function calling and operators 2) that fact that "append an item and make a new list" isn't supported by either a method or an operator, so we have to do a kludge to use +. And I think a big one that inspires these ideas: 3) When nesting function calling, you write (and read) the code in the reverse order that the operations take place: First you add the item to the list, then you sort it, then you slice it. 4) the "functional" form -- e.g. sorted() doesn't preserve type -- whether you sort a list or a tuple, you get a list back. So is the goal here to get "fluent" syntax for stringing mutating operations together that mutate the object? If so, then that should be clearly different than string together immutables. That is if I see: that = this.a_method().another_method() It should be really obvious whether or not "this" has been altered! Right now, if the object in question follows python conventions, then it has not been altered. Personally, I think Python has enough ways to apply an operation, but maybe in the spirit of functional programming's idea that we shouldn't be mutating collections at all, we should extend the mutable sequence ABC with methods that return new objects: list.sorted() list.appended() list.extended() ... (slicing already copies). Then you could work with mutable and immutable sequences similarly to how we do with strings: first_ten = a_list.appended(item).sorted()[:10] -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Wed Feb 20 20:55:00 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 21 Feb 2019 12:55:00 +1100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: <20190221015500.GM4465@ando.pearwood.info> On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote: > Here's a syntax that solves this using the new operators _:= and ,_ Be careful about making such dogmatic statements. Language design is not a matter of picking random syntax and claiming that it solves the problem -- especially when it doesn't solve the problem. Putting aside the aethestics of your suggestions (I think they are as ugly as sin), both of them are currently legal code, since a single underscore _ is a legal identifier. Starting in 3.8, _:= is the left hand side of an assignment expression assigning to the variable "_", so your suggestion: _:= a already has meaning in Python. That's a new feature, and you can be forgiven for perhaps not knowing about it. But the second suggestion is a very old feature, going back to Python 1 days. ,_ is part of a tuple or argument list including a variable called "_". You probably could have discovered this for yourself by trying something like this in the interactive interpreter: py> x = [] py> x,_.append(1) Traceback (most recent call last): File "", line 1, in AttributeError: 'tuple' object has no attribute 'append' The actual result you would get (an exception, or a tuple) will depend on the history of your current session, but whatever result you get it will show that it is already legal syntax. That means that there's going to be an ambiguity between your hoped-for semantics and the existing semantics: _:= a ,_.b would mean a tuple with two items: _:= a _.b rather than a chained method call as you hoped. > a = [1,2,3] > ( _:= a ,_ .append(4) ,_ .sort() ) > > > Personally, I find this a bit harder to read on one line and would break it > up like this: > > (_:= a > ,_ .append(4) > ,_ . .sort() > ) That's currently legal code which assigns a to _ then builds a tuple (or at least attempts to build a tuple) consisting of: a None None after calling a.append and a.sort. But there's a deeper problem with this entire concept, regardless of syntax, one which to my knowledge nobody has mentioned yet: it simply isn't compatible with the way operators work in Python at the moment. More on this in another post (coming soon). -- Steven From abedillon at gmail.com Wed Feb 20 21:18:57 2019 From: abedillon at gmail.com (Abe Dillon) Date: Wed, 20 Feb 2019 20:18:57 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <5c6c0d9e.1c69fb81.477b6.a66e@mx.google.com> Message-ID: [Chris Angelico] > Not about HOW it works. That's irrelevant. You DO need to know about > what it does, which is what I said. So it is. I'm sorry I misread your comment. [Chris Angelico] > In the case of random.choice, that's very clearly defined by its > documentation: it chooses a random > element from the thing you give it. If you don't know that, you have to > look it up to determine whether that's the problem. I think you're missing the point. The name random.choice alone, doesn't fully describe its interface, yet the first time I came across it in code, I didn't feel the need to go look into documentation. I'm betting you could make a pretty good educated guess of the interface of all the functions in the code I wrote above. Humans aren't computers. We can and do deal with ambiguity all the time. We can usually make a pretty good guess whether we need to drill down into a function to find a bug even if we don't know EVERYTHING about what the function does. Sometimes that educated guess is wrong and we have to back up and look at things we initially thought were irrelevant, but we're not as brittle to ambiguity as you seem to think. On Wed, Feb 20, 2019 at 7:35 PM Chris Angelico wrote: > On Thu, Feb 21, 2019 at 12:26 PM Abe Dillon wrote: > > You don't need to know EVERYTHING about how block_fork works to debug > that failure. You > > probably don't need to know EVERYTHING about how random.choice works > either. You don't > > need to know about how most of the functions in the code work. The code > is not blocking an > > opponent's win. The fault must be in "win" or "opposite". > > Not about HOW it works. That's irrelevant. You DO need to know about > what it does, which is what I said. In the case of random.choice, > that's very clearly defined by its documentation: it chooses a random > element from the thing you give it. If you don't know that, you have > to look it up to determine whether that's the problem. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Wed Feb 20 21:41:35 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Wed, 20 Feb 2019 18:41:35 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: Most of this thread is all just so much opinion, so I have avoided chiming in -- but as for opinion: A better way to list arguments is only one indentation level above the > current: > > variable = some_class.method( > argument=value, > argument2=value) > God no! I HATE that style -- for me, it makes it MUCH harder to read -- even more so if the variable names are a bit longer. But if you are going to do it, for the love of god, use more than four spaces! four spaces is one indentation, one indentation is how a code block is delineated in Python -- this is NOT a code block. It should not look like one. By the way, this is much worse for, say, function definitions: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() How can anyone think that's more readable than (view with fixed-width font if this email doesn't already do that for you): def a_function_with_lots_of_params(param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() This puts the parameter definitions over on the right, after the function name, where they belong, and makes it very clear where the definition ends and the function code begins. But if you HAVE to put it off to the left for I don't know why, at least put some extra space in there: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else): now_a_line_of_code = this_thing() The parameters are still in an odd place, but at least it's clear where the body of the function begins. If you need more convincing, consider functions with fewer params, and how they look compared to ones with many: def a_function_with_few_params(param1, param2): now_a_line_of_code = this_thing() then: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else) now_a_line_of_code = this_thing() why am I looking in a different place for the parameters when there are more of them?? Trying to match the indentation of the opening line is less readable > > variable = some_class.method(argument=value, > argument2=value) > this is more readable to me :-) > and less robust to refactoring: > var = cls.method(argument=value, > argument2=value) > well, that is an issue that I do face, but I blame it on my crappy tools :-) But YAPF does it the way I like :-) Except in the case of the "facebook" style -- yeach!) https://yapf.now.sh/ Facebook style: def a_function_with_lots_of_params( param1, param2, kwarg1=something, kwarg2=something_else ): now_a_line_of_code = this_thing() Anyway, PEP8 is officially for the standard library, but it HAS become a python-wide standard. As such, it simply needs to be flexible on some of these opinionated issues -- so both of the above styles are OK, as is adjusting your max line length up some. So at most, I'd say rewording this: """ Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. """ To be a bit less harsh would be a fine idea -- that is, change the clause: "For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay ..." To maybe just "For code maintained by a team that can reach agreement on this issue, it is okay ..." Then we can all go back to bike-shedding something else. -CHB PS -- I personally use 95 char per line :-) -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Wed Feb 20 21:48:08 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 21 Feb 2019 13:48:08 +1100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <20190221015500.GM4465@ando.pearwood.info> References: <20190220151028.GK4465@ando.pearwood.info> <20190221015500.GM4465@ando.pearwood.info> Message-ID: <20190221024808.GN4465@ando.pearwood.info> On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote: > On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote: > > > Here's a syntax that solves this using the new operators _:= and ,_ > > Be careful about making such dogmatic statements. Ah, I have just spotted your later explanation that you aren't referring to *new operators* spelled as _:= and ,_ (as I understood from your words) but as *existing syntax* that works today (at least in the most up-to-date version of 3.8). That pretty much makes all my previous objections to these "new operators" redundant, as they aren't operators at all. I'll point out that there's nothing special about the use of an underscore here. Instead of your snippet: _:= a ,_ .append(4) ,_ .sort() we could write: tmp := a, tmp.append(4), tmp.sort() So this is hardly method chaining or a fluent interface. (Hence my confusion -- I thought you were suggesting a way to implement a fluent interface.) If this were an Obfuscated Python competition, I'd congratulate you for the nasty trick of putting whitespace in non-standard positions to conceal what is going on. But in real code, that's only going to cause confusion. (But I think you acknowledge that this trick is not easy to read.) But it's also sub-optimal code. Why introduce a temporary variable instead of just writing this? a.append(4), a.sort() The only advantage of _ is that it is a one-character name. But there are other one character names which are less mystifying: a := some_long_identifier, a.append(4), a.sort() But why create a tuple filled mostly with None? Python is slow enough as it is without encouraging such anti-patterns. a := some_long_identifier; a.append(4); a.sort() Now no tuple is created, and doesn't need to be garbage collected. But this is still not a fluent interface. Its just cramming multiple statements into a single line. Which means you can't do this: function(arg1, mylist.append(1).sort(), arg3) -- Steven From 2QdxY4RzWzUUiLuE at potatochowder.com Thu Feb 21 00:27:55 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Wed, 20 Feb 2019 23:27:55 -0600 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: <3516c06b-e419-bab0-a89e-81068e261554@potatochowder.com> On 2/20/19 7:46 PM, Christopher Barker wrote: > mutating operations vs copying operations > > functions vs methods. > > This has a lot of impact on the design, and it's very important that > any final syntax makes these distinctions clear. Absolutely. > On Wed, Feb 20, 2019 at 8:33 AM Dan Sommers > <2QdxY4RzWzUUiLuE at potatochowder.com> wrote: > > It's a different way of doing things. Please don't conflate them. > > however, that's kind of what this thread is all about :-) And I'm objecting to it. :-) > So is the goal here to get "fluent" syntax for stringing mutating > operations together that mutate the object? Not my goal, no. > ... we should extend the mutable sequence > ABC with methods that return new objects: > > list.sorted() > list.appended() > list.extended() Call me +0, or maybe +0.5 if adding such additional methods prevent adding new syntax. Dan From abedillon at gmail.com Thu Feb 21 01:56:50 2019 From: abedillon at gmail.com (Abe Dillon) Date: Thu, 21 Feb 2019 00:56:50 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: [Christopher Barker] > God no! I HATE that style -- for me, it makes it MUCH harder to read -- > even more so if the variable names are a bit longer. > But if you are going to do it, for the love of god, use more than four > spaces! four spaces is one indentation, one indentation is how a code block > is delineated in Python -- this is NOT a code block. It should not look > like one. Holly hell! I'm sorry I insulted your mother or whatever serious crime I committed. Yes, I agree that two levels of indentation is an improvement and is in-fact how I write function definitions. [Christopher Baker] > this is more readable to me :-) I wish you would have watched the video I linked so I wouldn't have to make all the same arguments, but in the context of code running off the edge of a window, having the argument list hidden out there with arbitrary indentation is definitely a readability issue. [Christopher Baker] > This puts the parameter definitions over on the right, after the function > name, where they belong According to whom? [Christopher Baker] > if you HAVE to put it off to the left for I don't know why, at least put > some extra space in there: > def a_function_with_lots_of_params( > param1, > param2, > kwarg1=something, > kwarg2=something_else): > now_a_line_of_code = this_thing() > The parameters are still in an odd place, but at least it's clear where > the body of the function begins. If you'd seen my other replies in this very thread, you'd see that's exactly the style I use. [Christopher Baker] > well, that is an issue that I do face, but I blame it on my crappy tools > :-) I consider it a good thing that your tools don't facilitate bad coding style ;) This is just more Stockholm syndrome. Nowhere else will you see people consider cramming valuable information off into the right margin with arbitrary indentation "good design". You won't see it in prose. You won't see it in mathematical notation. You won't see it anywhere else. On Wed, Feb 20, 2019 at 8:42 PM Christopher Barker wrote: > Most of this thread is all just so much opinion, so I have avoided chiming > in -- but as for opinion: > > > > A better way to list arguments is only one indentation level above the >> current: >> >> variable = some_class.method( >> argument=value, >> argument2=value) >> > > God no! I HATE that style -- for me, it makes it MUCH harder to read -- > even more so if the variable names are a bit longer. > > But if you are going to do it, for the love of god, use more than four > spaces! four spaces is one indentation, one indentation is how a code block > is delineated in Python -- this is NOT a code block. It should not look > like one. > > > > By the way, this is much worse for, say, function definitions: > > def a_function_with_lots_of_params( > param1, > param2, > kwarg1=something, > kwarg2=something_else): > now_a_line_of_code = this_thing() > > How can anyone think that's more readable than (view with fixed-width font > if this email doesn't already do that for you): > > def a_function_with_lots_of_params(param1, > param2, > kwarg1=something, > kwarg2=something_else): > now_a_line_of_code = this_thing() > > This puts the parameter definitions over on the right, after the function > name, where they belong, and makes it very clear where the definition ends > and the function code begins. But if you HAVE to put it off to the left for > I don't know why, at least put some extra space in there: > > def a_function_with_lots_of_params( > param1, > param2, > kwarg1=something, > kwarg2=something_else): > now_a_line_of_code = this_thing() > > The parameters are still in an odd place, but at least it's clear where > the body of the function begins. > > If you need more convincing, consider functions with fewer params, and how > they look compared to ones with many: > > def a_function_with_few_params(param1, param2): > now_a_line_of_code = this_thing() > > then: > > def a_function_with_lots_of_params( > param1, > param2, > kwarg1=something, > kwarg2=something_else) > now_a_line_of_code = this_thing() > > why am I looking in a different place for the parameters when there are > more of them?? > > Trying to match the indentation of the opening line is less readable >> >> variable = some_class.method(argument=value, >> argument2=value) >> > > this is more readable to me :-) > > > and less robust to refactoring: > > >> var = cls.method(argument=value, >> argument2=value) >> > > well, that is an issue that I do face, but I blame it on my crappy tools > :-) > > But YAPF does it the way I like :-) > > Except in the case of the "facebook" style -- yeach!) > > https://yapf.now.sh/ > > Facebook style: > > def a_function_with_lots_of_params( > param1, param2, kwarg1=something, kwarg2=something_else > ): > now_a_line_of_code = this_thing() > > Anyway, PEP8 is officially for the standard library, but it HAS become a > python-wide standard. As such, it simply needs to be flexible on some of > these opinionated issues -- so both of the above styles are OK, as is > adjusting your max line length up some. > > So at most, I'd say rewording this: > > """ > Some teams strongly prefer a longer line length. For code maintained > exclusively or primarily by a team that can reach agreement on this issue, > it is okay to increase the nominal line length from 80 to 100 characters > (effectively increasing the maximum length to 99 characters), provided that > comments and docstrings are still wrapped at 72 characters. > """ > > To be a bit less harsh would be a fine idea -- that is, change the clause: > > "For code maintained exclusively or primarily by a team that can reach > agreement on this issue, it is okay ..." > > To maybe just > > "For code maintained by a team that can reach agreement on this issue, it > is okay ..." > > Then we can all go back to bike-shedding something else. > > -CHB > > PS -- I personally use 95 char per line :-) > > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brenbarn at brenbarn.net Thu Feb 21 02:26:51 2019 From: brenbarn at brenbarn.net (Brendan Barnwell) Date: Wed, 20 Feb 2019 23:26:51 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: <5C6E52BB.2070500@brenbarn.net> On 2019-02-20 18:41, Christopher Barker wrote: > God no! I HATE that style -- for me, it makes it MUCH harder to read -- > even more so if the variable names are a bit longer. > > But if you are going to do it, for the love of god, use more than four > spaces! four spaces is one indentation, one indentation is how a code > block is delineated in Python -- this is NOT a code block. It should not > look like one. I feel the complete opposite. "One indentation" is the only unit in multiples of which anything should ever be indented. Using arbitrary "indentation" to visually line things up is horrible. Everything gets indented by an integer number of indentation levels. It was mentioned earlier on this thread, but I think the real problem is editors. Specifically, people have become used to certain editor behaviors and conventions which are not actually that great, and as a result editors have not emphasized features which would be better. Even more specifically, people have not insisted that editors be designed to support a reader-oriented, rather than writer-oriented, approach to code display. In other words, visual details how the code is displayed should be up to person reading the code, not the person who wrote it. Instead, people have apparently for a long time insisted on the reverse, namely editors which format things as the code is written, by inserting actual characters in the file to make things like up visually. Characters shouldn't be in the file to make things like up visually; they should be there for their semantic importance. If that is done, then the editor can render those semantics in different ways according to the viewer's preference. The problem is that editors don't do this, because people have somehow gotten the idea that this would be a bad thing. So instead we have to argue over things like this, because whatever purely cosmetic choices one person makes in indenting his or her code become baked into the actual bytes of the file, and cannot be rendered differently later according to the preferences of a different viewer. I've rather forlornly given up on dealing with any of this. I use an editor that VISUALLY wraps long lines and maintains the indentation on the wrapped portion, without changing the bytes in the file. I make my lines as long as I want, inserting linebreaks only where they have a semantic reason to be (such as between multiple long conditions in an "if"). Everything is fine, until someone else looks at the code, and they have an editor that is only designed to display code that has the formatting baked into the whitespace. As a result, I consider this issue pretty much moot. There is no reason for the line length limit to be set to 100 or 120 or anything else. There are already too many problems with PEP 8 that stem from a desire to use whitespace for visual alignment rather than semantics (such as using spaces instead of tabs). So I just basically ignore PEP 8 and follow my own style, which happens to overlap in some respects with PEP 8 and diverge from it in others. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown From lele at metapensiero.it Thu Feb 21 02:50:58 2019 From: lele at metapensiero.it (Lele Gaifax) Date: Thu, 21 Feb 2019 08:50:58 +0100 Subject: [Python-ideas] PEP 8 update on line length References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: <8736oha8bh.fsf@metapensiero.it> Abe Dillon writes: > A better way to list arguments is only one indentation level above the > current: > > variable = some_class.method( > argument=value, > argument2=value) > > Trying to match the indentation of the opening line is less readable and > less robust to refactoring: > > variable = some_class.method(argument=value, > argument2=value) > > var = cls.method(argument=value, > argument2=value) Yes, that's unfortunate, but I still prefer the latter, and usually I accept the hassle and realign the remaining lines. In hindsight, I wish someone with a powerful time machine could introduce the concept of "one-indent-level-and-half" for continuation lines: the statement that most annoys me is the "if" when the condition is very long, because my eyes suffer when I see the following: if condition1 and \ condition2 and \ condition3: do_something() or even if (condition1 and condition2 and condition3): do_something() at the point that I usually use a double paren just to have one single space of difference between the continued condition elements and the succeeding suite: if ((condition1 and condition2 and condition3)): do_something() ciao, lele. -- nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. lele at metapensiero.it | -- Fortunato Depero, 1929. From benrudiak at gmail.com Thu Feb 21 02:51:17 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Wed, 20 Feb 2019 23:51:17 -0800 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 2:43 AM Chris Angelico wrote: > That's because a generator function conceptually has three ways to > provide data (yield, return, and raise), but mechanically, one of them > is implemented over the other ("return" is "raise StopIteration with a > value"). For other raised exceptions, this isn't a problem. Other functions also conceptually have three ways of returning: ordinary return with a value, a documented special return like KeyError, and pass-through exceptions. If the pass-through exception is KeyError, it gets conflated with the documented exceptional return, but correct code should handle them differently. It doesn't matter whether the syntax for the documented special return is "return x" or "raise KeyError(x)". I've never been screwed by this as badly with other exceptions as I was by StopIteration, but it's a general problem with the design of exceptions. I don't think exception specifications would solve that problem since you probably couldn't describe the KeyError's origin in the spec either. But that doesn't mean it isn't a problem. From pythonchb at gmail.com Thu Feb 21 02:58:37 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Wed, 20 Feb 2019 23:58:37 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 10:57 PM Abe Dillon wrote: > I wish you would have watched the video I linked > > that is an hour and 7 minute video! And I did watch some of it, and do agree with much of it. By the way, everyone should watch one of Jack Diederich's "naming things once videos as well: https://www.youtube.com/watch?v=hZ7hgYKKnF0 > but in the context of code running off the edge of a window, > I never said anything about running off the edge of the window -- if you put all your parameters on their own line, and don't use insanely long names, that will not be an issue. Keeping it to 72 chars is virtually never a problem. > having the argument list hidden out there > nothing hidden about it --it's exactly where a single argument would be -- does anyone advocate putting a single parameter or argument on the next line? But my core point really was these are all matter of opiniion, and it's a godo thing that PEP 8 allows some variation. > This puts the parameter definitions over on the right, after the function >> name, where they belong > > > According to whom? > According to me, of course. But it is wehre a single parameter would be, yes? > [Christopher Baker] > >> if you HAVE to put it off to the left for I don't know why, at least put >> some extra space in there: >> def a_function_with_lots_of_params( >> param1, >> param2, >> kwarg1=something, >> kwarg2=something_else): >> now_a_line_of_code = this_thing() >> The parameters are still in an odd place, but at least it's clear where >> the body of the function begins. > > > If you'd seen my other replies in this very thread, you'd see that's > exactly the style I use. > I've lost track of who advocates what style, but I was responding to someone that specifically advocated one level of indentation -- which is really the worst option. [Christopher Baker] > >> well, that is an issue that I do face, but I blame it on my crappy tools >> :-) > > > I consider it a good thing that your tools don't facilitate bad coding > style ;) > mostly they don't facilitate any of these styles in this context (I've been meaning to write a plugin for sublime that does, but haven't gotten around to it ). But the point is that handling indenting is really something the tools should do for you -- choosing a style for "ease of refactoring" should be pointless. > This is just more Stockholm syndrome. > honestly, I haven't chooses this style due to having been forced (or even encouraged) to use it -- I spend more time re-aligning code to make it the way I want it -- so no, I"ve come on this 'cuse it fits my brain better. > Nowhere else will you see people consider cramming valuable information > off into the right margin with arbitrary indentation "good design". > It's not the margin, and it's not arbitrary. > You won't see it in prose. You won't see it in mathematical notation. You > won't see it anywhere else. > Actually, I"ve seen in it math, where you have an "array" of equations, and > tabular information with columns on the right being important is not the > least bit rare. > > But if you are going to do it, for the love of god, use more than four > > spaces! four spaces is one indentation, one indentation is how a code > > block is delineated in Python -- this is NOT a code block. It should not > > look like one. > I feel the complete opposite. "One indentation" is the only unit > in > multiples of which anything should ever be indented. Using arbitrary > "indentation" to visually line things up is horrible. Everything gets > indented by an integer number of indentation levels. OK, then use two indentation levels for the parameter stack -- just don't use one -- that really is the worst option -- one indentation has real meaning in code. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Thu Feb 21 03:04:25 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Thu, 21 Feb 2019 00:04:25 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <8736oha8bh.fsf@metapensiero.it> References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> <8736oha8bh.fsf@metapensiero.it> Message-ID: On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax wrote: > that most annoys me is the "if" when the condition is very long, because my > eyes suffer when I see the following: > yup -- "if (" is four spaces -- exactly one indentation level -- that is really painful. I've got to figure out how to get flake8 to stop yelling at me for making that more readable :-) of difference between the continued condition elements and the succeeding > suite: > > if ((condition1 > and condition2 > and condition3)): > do_something() > ouch! ehy not jsut do: if (condition1 and condition2 and condition3)): do_something() (or any number of other options) and teach your linter that that's OK (or ignore your linter) -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Thu Feb 21 03:05:55 2019 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 21 Feb 2019 19:05:55 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Thu, Feb 21, 2019 at 6:51 PM Ben Rudiak-Gould wrote: > > On Wed, Feb 20, 2019 at 2:43 AM Chris Angelico wrote: > > That's because a generator function conceptually has three ways to > > provide data (yield, return, and raise), but mechanically, one of them > > is implemented over the other ("return" is "raise StopIteration with a > > value"). For other raised exceptions, this isn't a problem. > > Other functions also conceptually have three ways of returning: > ordinary return with a value, a documented special return like > KeyError, and pass-through exceptions. If the pass-through exception > is KeyError, it gets conflated with the documented exceptional return, > but correct code should handle them differently. It doesn't matter > whether the syntax for the documented special return is "return x" or > "raise KeyError(x)". Not sure what you mean here. If the documented special return is "return x", then it's a value that's being returned. That's completely different from raising some sort of exception. You have a reasonable point about raising KeyError. It's hard to catch bugs inside __getitem__ that result in the leakage of a KeyError. But it's not uncommon to implement getitem over some other object's getitem, which means that leakage is absolutely correct. I'm not sure what could really be done about that, but I'm also not sure it's necessary; those special methods tend to be very short. If you're writing a large and complex __getitem__, it might be worth adding some overhead to help with potential debugging, maybe wrapping most of your logic in a generator and having "yield" become "return", "return" become "raise KeyError", and "raise KeyError" become "raise RuntimeError". Easy enough with a decorator if you want it. Unnecessary overhead for most classes though. ChrisA From pythonchb at gmail.com Thu Feb 21 03:09:54 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Thu, 21 Feb 2019 00:09:54 -0800 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Wed, Feb 20, 2019 at 11:52 PM Ben Rudiak-Gould wrote: > Other functions also conceptually have three ways of returning: > ordinary return with a value, a documented special return like > KeyError, and pass-through exceptions. well, I wouldn't call that three ways of returning... But yes, there is no (easy) way to distinguish an Exception raised by the function you called, and one raised somewhere deeper that. And I have been bitten by that more than once. It makes "Easier to ask forgiveness than permission" kind of tricky. But I've found that good unit tests help a lot. And Exception handling is messy -- the point made by the OP, I'm not sure there's a better way to do it. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From lele at metapensiero.it Thu Feb 21 03:12:02 2019 From: lele at metapensiero.it (Lele Gaifax) Date: Thu, 21 Feb 2019 09:12:02 +0100 Subject: [Python-ideas] PEP 8 update on line length References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> <8736oha8bh.fsf@metapensiero.it> Message-ID: <87y3698srx.fsf@metapensiero.it> Christopher Barker writes: > On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax wrote: > >> if ((condition1 >> and condition2 >> and condition3)): >> do_something() >> > > ouch! ehy not jsut do: > > if (condition1 > and condition2 > and condition3)): > do_something() > > (or any number of other options) > > and teach your linter that that's OK (or ignore your linter) Because I would first need to teach Emacs the aforementioned "indent-and-half" for continuation lines :-) ciao, lele. -- nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. lele at metapensiero.it | -- Fortunato Depero, 1929. From greg.ewing at canterbury.ac.nz Thu Feb 21 03:30:08 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 21 Feb 2019 21:30:08 +1300 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5C6E52BB.2070500@brenbarn.net> References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> <5C6E52BB.2070500@brenbarn.net> Message-ID: <5C6E6190.7040604@canterbury.ac.nz> Brendan Barnwell wrote: > I use > an editor that VISUALLY wraps long lines and maintains the indentation > on the wrapped portion, without changing the bytes in the file. I make > my lines as long as I want, inserting linebreaks only where they have a > semantic reason to be (such as between multiple long conditions in an > "if"). I don't think that taking an excessively long line of code and mechanically wrapping it to a narrower width makes in any easier to read. Like you say, readability relies on making intelligent decisions about where to break lines based on their semantics. So even if everyone is equipped with an auto-wrapping code editor, there is still going to be code that really needs at least N characters of width to display properly, and looks terrible when wrapped to anything less. Think about how annoying it is when an email message gets re-wrapped to a slightly narrower width than it was originally written with -- and apply that to code. -- Greg From steve at pearwood.info Thu Feb 21 06:04:07 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 21 Feb 2019 22:04:07 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: <20190221110406.GO4465@ando.pearwood.info> On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote: [Ben] > > Other functions also conceptually have three ways of returning: > > ordinary return with a value, a documented special return like > > KeyError, and pass-through exceptions. If the pass-through exception > > is KeyError, it gets conflated with the documented exceptional return, > > but correct code should handle them differently. It doesn't matter > > whether the syntax for the documented special return is "return x" or > > "raise KeyError(x)". > > Not sure what you mean here. If the documented special return is > "return x", then it's a value that's being returned. That's completely > different from raising some sort of exception. I think I understand what Ben means, because I think I've experimented with functions which do what he may be getting at. Remember that exceptions are not necessarily errors. So you might write a function which returns a value in the standard case, but raises an exception to represent an exceptional case. If this is not an error, then the caller ought to be prepared for the exception and always catch it. This could be considered an alternative design to returning a tuple: (True, value) # standard case (False,) # or raise an exception If this seems strange, it actually isn't *that* strange. It is very similar to the way iterators yield a value in the standard case, and raise StopIteration to signal the non-standard, non-erroneous but exception case of having reached the end of the iterator. Another potential example would be searching, where "Not Found" is not necessarily an error, but it is always an exceptional case. The built-ins raise KeyError or ValueError (for str.index) but they could have just as easily raise KeyNotFound and SubstringNotFound. So exceptions do not necessarily represent errors that should bubble up to the user, to be reported as a bug. They can also represent an alternative (if slightly clumsy) mechanism for passing information to the caller. -- Steven From rosuav at gmail.com Thu Feb 21 06:21:28 2019 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 21 Feb 2019 22:21:28 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: <20190221110406.GO4465@ando.pearwood.info> References: <20190219231247.GE4465@ando.pearwood.info> <20190221110406.GO4465@ando.pearwood.info> Message-ID: On Thu, Feb 21, 2019 at 10:04 PM Steven D'Aprano wrote: > > On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote: > > [Ben] > > > Other functions also conceptually have three ways of returning: > > > ordinary return with a value, a documented special return like > > > KeyError, and pass-through exceptions. If the pass-through exception > > > is KeyError, it gets conflated with the documented exceptional return, > > > but correct code should handle them differently. It doesn't matter > > > whether the syntax for the documented special return is "return x" or > > > "raise KeyError(x)". > > > > Not sure what you mean here. If the documented special return is > > "return x", then it's a value that's being returned. That's completely > > different from raising some sort of exception. > > I think I understand what Ben means, because I think I've experimented > with functions which do what he may be getting at. > > Remember that exceptions are not necessarily errors. So you might write > a function which returns a value in the standard case, but raises an > exception to represent an exceptional case. If this is not an error, > then the caller ought to be prepared for the exception and always catch > it. Yep, I understand that part (and mention KeyError specifically). What I don't understand is the documented special return of "return x". If there's a way to return a magic value, then it's still just a value. For the rest, yeah, there's the normal Python behaviour of signalling "nope" by raising a specific exception. And yes, leaking an exception of the same type from within that function is going to be interpreted as that "nope". That's important to the ability to refactor - you can have a helper function that raises, and then the main __getitem__ or __getattr__ or whatever will just propagate the exception. That's why "leaking" is such a hard thing to pin down. ChrisA From pflarr at gmail.com Thu Feb 21 07:18:32 2019 From: pflarr at gmail.com (Paul Ferrell) Date: Thu, 21 Feb 2019 05:18:32 -0700 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> <8736oha8bh.fsf@metapensiero.it> Message-ID: My linter is fine with a double indent after an 'if (A and'. I thought it was in the standard. (Pycharm's built-in pep-8 highlighter) On Thu, Feb 21, 2019, 1:04 AM Christopher Barker On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax wrote: > >> that most annoys me is the "if" when the condition is very long, because >> my >> eyes suffer when I see the following: >> > > yup -- "if (" is four spaces -- exactly one indentation level -- that is > really painful. > > I've got to figure out how to get flake8 to stop yelling at me for making > that more readable :-) > > of difference between the continued condition elements and the succeeding >> suite: >> >> if ((condition1 >> and condition2 >> and condition3)): >> do_something() >> > > ouch! ehy not jsut do: > > if (condition1 > and condition2 > and condition3)): > do_something() > > (or any number of other options) > > and teach your linter that that's OK (or ignore your linter) > > -CHB > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Thu Feb 21 07:22:04 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 21 Feb 2019 23:22:04 +1100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <20190221015500.GM4465@ando.pearwood.info> References: <20190220151028.GK4465@ando.pearwood.info> <20190221015500.GM4465@ando.pearwood.info> Message-ID: <20190221122204.GP4465@ando.pearwood.info> Correcting myself twice now, that's not a good sign... :-) On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote: > But there's a deeper problem with this entire concept, regardless of > syntax, one which to my knowledge nobody has mentioned yet: it simply > isn't compatible with the way operators work in Python at the moment. > More on this in another post (coming soon). On further thought, I would like to withdraw that claim. Actual operators like + - etc of course are implemented using dunder methods, but "pseudo-operators" like the dot aren't. If we had such a fluent method chain operator, it would be more like dot than ordinary operators. -- Steven From p.f.moore at gmail.com Thu Feb 21 07:25:52 2019 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 21 Feb 2019 12:25:52 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> <8736oha8bh.fsf@metapensiero.it> Message-ID: On Thu, 21 Feb 2019 at 12:20, Paul Ferrell wrote: > > My linter is fine with a double indent after an 'if (A and'. I thought it was in the standard. If I used a linter, I'd expect it to be fine with whatever I told it to be fine with :-) It's a linter's job to flag up violations of the coding style *I* choose to follow, not to impose a coding style on me that I don't agree with. Paul From robertve92 at gmail.com Thu Feb 21 10:31:30 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Thu, 21 Feb 2019 16:31:30 +0100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <20190221122204.GP4465@ando.pearwood.info> References: <20190220151028.GK4465@ando.pearwood.info> <20190221015500.GM4465@ando.pearwood.info> <20190221122204.GP4465@ando.pearwood.info> Message-ID: In funcoperators, because the dot operator is just syntaxic sugar for functions getattr and setattr with a string, a.hello.world # can be implemented using infix a -o- 'hello' -o- 'world' # or using postfix a |dot('hello') |dot('world') # using from funcoperators import postfix, infix o = infix(getattr) def dot(n): return postfix(lambda x: getattr(x, n)) For methods, one could write : a.upper().replace('x', 'y') # can be implemented by a |meth('upper') |meth('replace', 'x', 'y') # using def meth(x, *a, **b): return postfix (lambda self: getattr(self, x)(*a, **b)) And one could do upper = postfix(str.upper) def replace(*a, **b): return postfix(lambda self: self.replace(*a, **b)) # to be able to do : a |upper |replace('a', 'b') And of course you can create your own functions to have the behavior you want. robertvandeneynde.be On Thu, 21 Feb 2019, 13:22 Steven D'Aprano, wrote: > Correcting myself twice now, that's not a good sign... :-) > > On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote: > > > But there's a deeper problem with this entire concept, regardless of > > syntax, one which to my knowledge nobody has mentioned yet: it simply > > isn't compatible with the way operators work in Python at the moment. > > More on this in another post (coming soon). > > On further thought, I would like to withdraw that claim. > > Actual operators like + - etc of course are implemented using dunder > methods, but "pseudo-operators" like the dot aren't. If we had such a > fluent method chain operator, it would be more like dot than ordinary > operators. > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhodri at kynesim.co.uk Thu Feb 21 10:44:02 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Thu, 21 Feb 2019 15:44:02 +0000 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> <20190221015500.GM4465@ando.pearwood.info> <20190221122204.GP4465@ando.pearwood.info> Message-ID: <0316eae4-e68c-d8ed-db9f-b083d48baa08@kynesim.co.uk> On 21/02/2019 15:31, Robert Vanden Eynde wrote: > In funcoperators, because the dot operator is just syntaxic sugar for > functions getattr and setattr with a string, [snip hideousness] I have to say, that's a pretty strong argument for not touching funcoperators with a ten foot bargepool. -- Rhodri James *-* Kynesim Ltd From rhodri at kynesim.co.uk Thu Feb 21 10:56:34 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Thu, 21 Feb 2019 15:56:34 +0000 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: References: <20190220151028.GK4465@ando.pearwood.info> <20190221015500.GM4465@ando.pearwood.info> <20190221122204.GP4465@ando.pearwood.info> <0316eae4-e68c-d8ed-db9f-b083d48baa08@kynesim.co.uk> Message-ID: On 21/02/2019 15:47, Robert Vanden Eynde wrote: > On Thu, 21 Feb 2019, 16:44 Rhodri James, wrote: > >> On 21/02/2019 15:31, Robert Vanden Eynde wrote: >>> In funcoperators, because the dot operator is just syntaxic sugar for >>> functions getattr and setattr with a string, >> [snip hideousness] >> >> I have to say, that's a pretty strong argument for not touching >> funcoperators with a ten foot bargepool. >> > > What do you mean ? > > I don't mind touching funcoperators, I try to understand the need and find > solutions using existing tools. > (I meant bargepole, not bargepool, obviously. Sorry about the typos, I have two other projects crowding my brain at the moment and may not make a great deal of sense.) I mean it looked horrible. If someone put code like that in front of me, I would assume that the writer was being clever for the sake of being clever and rewrite it in a way that I would probably be able to read later without half an hour of puzzling first. I flat out do not see the need for fluent operators. What the heck is wrong with putting separate operations on separate lines? It's easier to read, and gives you shorter lines into the bargin (see the 80-column argument going on elsewhere). -- Rhodri James *-* Kynesim Ltd From robertve92 at gmail.com Thu Feb 21 10:47:59 2019 From: robertve92 at gmail.com (Robert Vanden Eynde) Date: Thu, 21 Feb 2019 16:47:59 +0100 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <0316eae4-e68c-d8ed-db9f-b083d48baa08@kynesim.co.uk> References: <20190220151028.GK4465@ando.pearwood.info> <20190221015500.GM4465@ando.pearwood.info> <20190221122204.GP4465@ando.pearwood.info> <0316eae4-e68c-d8ed-db9f-b083d48baa08@kynesim.co.uk> Message-ID: On Thu, 21 Feb 2019, 16:44 Rhodri James, wrote: > On 21/02/2019 15:31, Robert Vanden Eynde wrote: > > In funcoperators, because the dot operator is just syntaxic sugar for > > functions getattr and setattr with a string, > [snip hideousness] > > I have to say, that's a pretty strong argument for not touching > funcoperators with a ten foot bargepool. > What do you mean ? I don't mind touching funcoperators, I try to understand the need and find solutions using existing tools. -------------- next part -------------- An HTML attachment was scrubbed... URL: From python-ideas at mgmiller.net Thu Feb 21 13:31:54 2019 From: python-ideas at mgmiller.net (Mike Miller) Date: Thu, 21 Feb 2019 10:31:54 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: <462ed88d-3a4c-dc60-1e57-a0fa245bdd5e@mgmiller.net> On 2/18/19 8:37 PM, Simon wrote: > I'd like to propose an update to PEP8. Indeed, the 80 characters per line > guideline is, I feel, outdated. Hi, I don't agree it is outdated. As someone who has a second 4k monitor in portrait mode to minimize scrolling (recommended), the ~80 char line limit avoids the need for horizontal scrolling as well. This isn't your father's Oldsmobile, haha. When in landscape on the go I can have two windows open side by side, say an editor and documentation/mail at the same time, aka multitasking. Not as good as a second monitor, but better than nothing. Other folks have chimed in on how newspapers and magazines limit line length for readability purposes. I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer lines might be desirable. Worked at a place where a co-worker frequently produced code with ~200 character lines despite calls to cease and desist. Looked over once, and sure enough a full+widescreen editor. Nostalgic for DOS, or focused like a laser? Not sure. The issue is unfortunately exacerbated by the monitor industry forcing us all to 16:9 aspect ratios, outside of the MacBook and tablets. That was a regression in my opinion. -Mike From pflarr at gmail.com Thu Feb 21 13:53:27 2019 From: pflarr at gmail.com (Paul Ferrell) Date: Thu, 21 Feb 2019 11:53:27 -0700 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <462ed88d-3a4c-dc60-1e57-a0fa245bdd5e@mgmiller.net> References: <462ed88d-3a4c-dc60-1e57-a0fa245bdd5e@mgmiller.net> Message-ID: I think the solution is for everyone to rotate their widescreen monitors 90? into a really tall portrait mode. :) On Thu, Feb 21, 2019, 11:44 AM Mike Miller wrote: > > On 2/18/19 8:37 PM, Simon wrote: > > I'd like to propose an update to PEP8. Indeed, the 80 characters per > line > > guideline is, I feel, outdated. > > Hi, I don't agree it is outdated. As someone who has a second 4k monitor > in > portrait mode to minimize scrolling (recommended), the ~80 char line limit > avoids the need for horizontal scrolling as well. This isn't your > father's > Oldsmobile, haha. > > When in landscape on the go I can have two windows open side by side, say > an > editor and documentation/mail at the same time, aka multitasking. Not as > good > as a second monitor, but better than nothing. > > Other folks have chimed in on how newspapers and magazines limit line > length for > readability purposes. > > I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer > lines > might be desirable. Worked at a place where a co-worker frequently > produced > code with ~200 character lines despite calls to cease and desist. Looked > over > once, and sure enough a full+widescreen editor. Nostalgic for DOS, or > focused > like a laser? Not sure. > > The issue is unfortunately exacerbated by the monitor industry forcing us > all to > 16:9 aspect ratios, outside of the MacBook and tablets. That was a > regression > in my opinion. > > -Mike > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymond.hettinger at gmail.com Thu Feb 21 14:59:56 2019 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Thu, 21 Feb 2019 11:59:56 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: On Feb 18, 2019, at 8:37 PM, Simon wrote: > > I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated. I concur. We now put expressions in f-strings and have assignment expressions that easily spill over 80 characters if one uses all but the most compact variable names. Comprehensions tend to make expressions longer. Queries and filters in Pandas also easily spill over. The 80 character limit pre-dates these evolutions of the language. In particular, the case where I most want to let people run with long lines is in forming messages to be displayed to a user. Templates can get fat even if the displayed message is not long. The code is more readable if people don't mangle their templates with line wrapping. class Frabawidget: ... @wozzle.setter def (self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) In doing code reviews, I see many fewer atrocities from long lines than I do from weird line-wraps and from variable names that have been over-shortened to make the line fit in 80 characters. To avoid these issues, my clients typically set their line limits at 90 or 100 (though I have one customer that keeps 80 characters but uses two-space indents, yuck). PEP 8 is mostly about readability. However, the line length limit often seems to cause less readable code. Raymond From python-ideas at mgmiller.net Thu Feb 21 16:10:23 2019 From: python-ideas at mgmiller.net (Mike Miller) Date: Thu, 21 Feb 2019 13:10:23 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <462ed88d-3a4c-dc60-1e57-a0fa245bdd5e@mgmiller.net> Message-ID: <04f7aab8-a941-0ead-0b7a-6f89a786e004@mgmiller.net> On 2/21/19 10:53 AM, Paul Ferrell wrote: > I think the solution is for everyone to rotate their widescreen monitors 90? > into a really tall portrait mode. :) Yep, that's what I do, but would prefer a squarer monitor so I could get two windows side by side on that one also. My old 1600x1200 4:3 in portrait allowed that comfortably. 16:10 might. -Mike From levkivskyi at gmail.com Thu Feb 21 17:28:43 2019 From: levkivskyi at gmail.com (Ivan Levkivskyi) Date: Thu, 21 Feb 2019 22:28:43 +0000 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: On Tue, 19 Feb 2019 at 21:07, Miikka Salminen wrote: > Hi! > > To help automatic document generators and static type checkers reason more > about the code, the possible side-effects and raised exceptions could also > be annotated in a standardized way. > The idea about "checked exceptions" appeared several times in various places. I used to think that this would be hard to support for any realistic use cases. But now I think there may be a chance to turn this into a usable feature if one frames it correctly (e.g. the focus could be on user defined exceptions, rather than on standard ones, since there is no way we can annotate every function in typeshed). But this is probably not the best place to the start the discussion (we may come back here if we will have a proposal). I would recommend to post either on typing GitHub tracker, or mypy GitHub tracker, or on typing SIG mailing list. IMO the part about side effects is a non-starter. -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pylang3 at gmail.com Thu Feb 21 17:32:12 2019 From: pylang3 at gmail.com (pylang) Date: Thu, 21 Feb 2019 17:32:12 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <04f7aab8-a941-0ead-0b7a-6f89a786e004@mgmiller.net> References: <462ed88d-3a4c-dc60-1e57-a0fa245bdd5e@mgmiller.net> <04f7aab8-a941-0ead-0b7a-6f89a786e004@mgmiller.net> Message-ID: Some feedback: I code on a 13.5 inch laptop. I split my screen between my browser on the left half and editor on the right half of the screen. The 80 character suggestion has been helpful to me in reading code. Otherwise I'd use up time with random horizontal scrolling. On Thu, Feb 21, 2019 at 4:11 PM Mike Miller wrote: > > On 2/21/19 10:53 AM, Paul Ferrell wrote: > > I think the solution is for everyone to rotate their widescreen monitors > 90? > > into a really tall portrait mode. :) > > Yep, that's what I do, but would prefer a squarer monitor so I could get > two > windows side by side on that one also. My old 1600x1200 4:3 in portrait > allowed > that comfortably. 16:10 might. > > -Mike > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Thu Feb 21 20:06:51 2019 From: chris.barker at noaa.gov (Chris Barker) Date: Thu, 21 Feb 2019 17:06:51 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger < raymond.hettinger at gmail.com> wrote: > I concur. We now put expressions in f-strings and have assignment > expressions that easily spill over 80 characters if one uses all but the > most compact variable names. Comprehensions tend to make expressions > longer. Queries and filters in Pandas also easily spill over. The 80 > character limit pre-dates these evolutions of the language. > > In particular, the case where I most want to let people run with long > lines is in forming messages to be displayed to a user. I agree here -- and if it's messages (also comments - a twenty char comment after a 70 char line should be fine!) then it's not part of the logic of the code -- so not as bd if there is some spill off the screen for those folks that do code on tablets ;-) Actually for me, the issue s comes up when I'm showing code on a projector -- I use a huge font so folks in the back can see) > class Frabawidget: > ... > @wozzle.setter > def (self, woozle): > if not (self.min_woozle < woozle < self.max_woozle): > raise ValueError(f"Expected woozle to be between > {self.min_woozle} and {self.max_woozle}") > self._wozzle = normalize(woozle) > That's 103 chars long -- and very readable. But, is this that much worse? class Frabawidget: ... @wozzle.setter def (self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between" "{self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) (it IS harder to write, that's for sure) In doing code reviews, I see many fewer atrocities from long lines than I > do from weird line-wraps and from variable names that have been > over-shortened to make the line fit in 80 characters. To avoid these > issues, my clients typically set their line limits at 90 or 100 and yet the above example was 103 ... you do need a limit somewhere. I actually would really like the "limit" to depend on what the line is -- that is, it's OK to go longer if it's essentially text -- message to the user, comment, etc., rather than part of the code logic. In fact, now that I write that, I think I actually DO do that -- and even add a # noqa sometimes so my linter will stop bugging me. A smart linter would be nice here. PEP 8 is mostly about readability. However, the line length limit often > seems to cause less readable code. > So what do you suggest? simply increase the recommended line length? Or would softening the language about extending it be enough? Maybe something along the lines of: A line length limit should be well defined for each project / organization -- 80 char per line is safest for all users, but anything up to 100 is appropriate if the team maintaining the code agrees. Raymond: As a core dev -- are suggesting extending the line limit for the standard library? To all the folks quoting theory: let's be honest. Yes, really long lines are harder to read, but the 80 char limit comes from old terminals, NOT any analysis that somehow that is optimum for readability. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From apalala at gmail.com Thu Feb 21 20:20:38 2019 From: apalala at gmail.com (=?UTF-8?Q?Juancarlo_A=C3=B1ez?=) Date: Thu, 21 Feb 2019 21:20:38 -0400 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi wrote: > The idea about "checked exceptions" appeared several times in various > places. I used to think that this would be hard to support for any > realistic use cases. But now I think there may be a chance > to turn this into a usable feature if one frames it correctly (e.g. the > focus could be on user defined exceptions, rather than on standard ones, > since there is no way we can annotate every function in typeshed). > It's well documented how checked exceptions lead to bad code. That's why C#, which came after Java, didn't include them. Exceptions may be logically thought as of part of the type of a method, and of the type of the method's class, but that requires that the type catches every exception that may be raised from the implementation and either handles it, or translates it to one belonging to the type. It's a lot of work, it's cumbersome, and it is fragile, as the exception handling may need to change over minor implementation changes. If dependencies don't treat the exceptions that may escape from them as part of the type, then our own types will need to be changes every time a dependency changes its implementation. The strategy of catching only exceptions of interest and letting others pass produces less fragile and easier to test code. -- Juancarlo *A?ez* -------------- next part -------------- An HTML attachment was scrubbed... URL: From klahnakoski at mozilla.com Thu Feb 21 20:20:05 2019 From: klahnakoski at mozilla.com (Kyle Lahnakoski) Date: Thu, 21 Feb 2019 20:20:05 -0500 Subject: [Python-ideas] add fluent operator to everything In-Reply-To: <20190220151028.GK4465@ando.pearwood.info> References: <20190220151028.GK4465@ando.pearwood.info> Message-ID: On 2019-02-20 10:10, Steven D'Aprano wrote: > Or if you're worried about the line length: > result = function(mystr.strip() > .expandtabs() > .lower() > .replace('ham', 'spam') > I think It seems that this fluency discussion, and the vector discussion is similar; I made a toy class [1] to demonstrate. It is much like DavidMertz's vector [2], but focused on chained methods . The `vector()` method lets us enter "vector mode". There are methods that act on elements (eg. map), methods that act on the whole (eg. sort), and methods that exit vector mode (eg. list). output = vector([3, 2, 1]).append(4).sort().limit(10).list() Fluency? can be had by entering vector mode on a singleton list: output = ( ??? vector([mystr]) ??? .strip() ??? .expandtabs() ??? .lower() ??? .replace("ham", "spam") ??? .map(function) ??? .first() ) Given vector() is quite succinct, and Numpy and Pandas do vector operations elegantly already, I do not think there is need for vectorized operators or fluency operators in Python. [1] My toy class - https://github.com/klahnakoski/mo-vector/blob/master/mo_vector/__init__.py [2] DavidMertz vector 0- https://github.com/DavidMertz/stringpy/blob/master/vector.py From benrudiak at gmail.com Thu Feb 21 21:34:21 2019 From: benrudiak at gmail.com (Ben Rudiak-Gould) Date: Thu, 21 Feb 2019 18:34:21 -0800 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: > It's well documented how checked exceptions lead to bad code. Please cite a paper. I know "everyone knows" that they're bad, but "everyone knows" a lot of things. Here's a recentish proposal by Herb Sutter to add a kind of checked exception to C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf He talks about some of the same issues I've talked about in this thread: in particular, that the farther exceptions propagate, the less likely that they can be handled in a precise way. In practice, exceptions are either handled early or they are handled generically (e.g. by printing a traceback). > Exceptions may be logically thought as of part of the type of a method, Yes, exceptions designed to be caught and handled by the caller are essentially alternate return values. Examples are KeyError for mapping lookups, FileNotFoundError for open(), etc. They are part of the method's interface whether they are encoded in a type system or not. > but that requires that the type catches every exception that may be raised from the implementation and either handles it, or translates it to one belonging to the type. What you're describing is strong static typing. Yes, it is a hassle. It means you have to do a lot of up-front work proving that your program will handle *every* case before the implementation will permit you to run it on *any* case. A lot of programmers don't like that. They want to write code that works for the cases they care about in the moment, and think about the other cases "later" (which in practice often means "after the product has shipped and someone files a bug report"). > It's a lot of work, it's cumbersome, and it is fragile, as the exception handling may need to change over minor implementation changes. Yes, it's a lot of work and cumbersome. In exchange for this extra effort, you get static guarantees that make it easier to reason about the behavior of the program. > The strategy of catching only exceptions of interest and letting others pass produces less fragile and easier to test code. It is less of a hassle to write unchecked code. I don't know if it's easier to test, but maybe. It isn't less fragile, at least not in the way I understand "fragile." Fragile code isn't code that is prone to compile-time type errors when it's changed. Fragile code is code that's prone to crashes or other broken behavior at runtime when it's changed, because of hidden constraints that weren't expressible in the type system. At least, that's what "fragile" means in "fragile base class problem." From apalala at gmail.com Thu Feb 21 22:26:17 2019 From: apalala at gmail.com (=?UTF-8?Q?Juancarlo_A=C3=B1ez?=) Date: Thu, 21 Feb 2019 23:26:17 -0400 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: On Thu, Feb 21, 2019 at 10:34 PM Ben Rudiak-Gould wrote: > > It's well documented how checked exceptions lead to bad code. > > Please cite a paper. I know "everyone knows" that they're bad, but > "everyone knows" a lot of things. > This is one of the original interviews touching why checked exceptions were not made part of C#: https://www.artima.com/intv/handcuffs.html The problem is that a code fragment should only catch exceptions that it expects, because it won't know what to do anything else but to wrap the exception into one of the enclosing type. But if every type has to define a SomethingWentWrongInTypeException wrapper exception, it's logical that all of them inherit from a standard SomethingWentWrongException. Having done that, the type-specific generic exceptions are of no value, because any code wanting to guard against the unexpected will just catch SomethingWentWrongException. And that brings us back to square one, which is letting unexpected exceptions through to wherever a clean shutdown or restart of the subsystem can be done. Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException. In the end, I think that allowing type-hints about exceptions that may be raised is quite useful, as long as they are not checked/enforced (in the style of Java). Many times I've missed a PyCharm hint me about the actual exceptions a given call may actually raise. Newer languages like Go and Swift shy away from exceptions because of the tendency to: try: # something except: print('oops!) -- Juancarlo *A?ez* -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosuav at gmail.com Thu Feb 21 22:32:30 2019 From: rosuav at gmail.com (Chris Angelico) Date: Fri, 22 Feb 2019 14:32:30 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: On Fri, Feb 22, 2019 at 2:27 PM Juancarlo A?ez wrote: > Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException. > That assumes atomicity. If you want an atomic "replace top of stack" that can never raise StackFullException, it's probably best to express it as stack.replacetop(x) rather than having something that might be interrupted. > Newer languages like Go and Swift shy away from exceptions because of the tendency to: > > try: > # something > except: > print('oops!) > People do dumb things with exceptions, yes. Why does this mean that they are bad? I don't understand this. Exception handling (and stack unwinding) gives an easy and clear way to refactor code without having to daisychain error handling everywhere. How is throwing that away going to help people write better code? But then, Golang also decided that Unicode wasn't necessary, and we should all deal with UTF-8 encoded byte sequences instead of text strings, so I'm fairly sure there are no ten foot barge poles long enough for me to touch it with. There are languages that have problems because of history (*cough*JavaScript*cough*), but for a new language to make multiple poor decisions just means it's one to avoid. ChrisA From 2QdxY4RzWzUUiLuE at potatochowder.com Thu Feb 21 23:01:03 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Thu, 21 Feb 2019 22:01:03 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: <8a7102ab-008b-d590-a87e-2536256d51da@potatochowder.com> On 2/21/19 7:06 PM, Chris Barker via Python-ideas wrote: > On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger > wrote: >> class Frabawidget: >> ... >> @wozzle.setter >> def (self, woozle): >> if not (self.min_woozle < woozle < self.max_woozle): >> raise ValueError(f"Expected woozle to be between >> {self.min_woozle} and {self.max_woozle}") >> self._wozzle = normalize(woozle) >> > That's 103 chars long -- and very readable. But, is this that much > worse? > class Frabawidget: > ... > @wozzle.setter > def (self, woozle): > if not (self.min_woozle < woozle < self.max_woozle): > raise ValueError(f"Expected woozle to be between" > "{self.min_woozle} and {self.max_woozle}") > self._wozzle = normalize(woozle) I remain against longer lines. I break 80 characters extremely rarely, if ever, and at times start breaking long lines before that. I find Chris's code more readable. I'm even more against for backwards incompatibility and hard-to-read exception messages. ;-) Chris's code doesn't quite match Raymond's; Chris lost a space between (ironically) "between" and "{self.min_woozle}." Dan From steve at pearwood.info Thu Feb 21 23:33:20 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 22 Feb 2019 15:33:20 +1100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: <20190222043320.GQ4465@ando.pearwood.info> On Thu, Feb 21, 2019 at 05:06:51PM -0800, Chris Barker via Python-ideas wrote: > To all the folks quoting theory: let's be honest. Yes, really long lines > are harder to read, but the 80 char limit comes from old terminals, NOT any > analysis that somehow that is optimum for readability. Chris, the convention to limit text to somewhere around 60-80 characters predates old terminals by *literally centuries*. I don't think it's *us* that needs to be told to "be honest". I don't know who first came up with this story that the 79 column limit is all about compatibility with old 80 char terminals, but it's just a story. (And did they ever stop to wonder why those old terminals standardized on 80 columns?) Compatibility with old terminals is "nice to have" if you ever need to ssh into a remote machine via an 80-column machine and edit code (and I know somebody who actually does that!), but that's not the reason why we should keep the 80 column limit as the default. (Many people have already spent a lot of words explaining some of the advantages of an 80 char limit, and I don't intend to go over them again. Go back and read the thread.) I've just grabbed a handful of books at random from my bookcase, and done a quick sample of number of chars per line: 42 letters plus whitespace = 52 characters 28 letters plus whitespace = 34 x 2 columns = 68 63 plus ws = 75 56 plus ws = 67 73 plus ws = 84 59 plus ws = 70 56 plus ws = 67 (another one!) I would be surprised if you found many books that reached 95-100 characters, and shocked if you found any at all that reached 120 characters. Based on this sample, I would say the typical line length for optimal reading of prose is about 60-70 chars. Call it 65. Add four leading idents of four spaces each, and our optimum is about 81 columns. The difference between that and PEP 8's 79 columns is not significant. (I for one would not fail your code in a review merely for reaching 81 or even 82 columns.) Now, it does have to be admitted that prose does not have the same characteristics as source code. Prose tends to have solid paragraphs of the same width, and we typically read large blocks of text in full. Whereas source code tends to have lots of short lines, and a few very long lines. We typically skim most of the text, then focus in tightly to study in detail a small section of the text at a time. And any limit we choose is going to be a compromise between the need to avoid giant one-liners and the nuisance value of splitting a conceptual line of code over multiple physical lines. Being a compromise, there will always be cases where it is sub-optimal. Nevertheless, we can say this about typical Python source code: 1. 79 characters is *very generous* for most lines of code; I did a quick sample of code and found an average of 51 columns including the leading indents. This is, of course, an imperfect and biased sample because long lines have been split to keep the 79 char limit, but even a brief glance at the std lib shows that most lines of code tend to fit within 50-60 characters. 2. When a single line goes beyond 80 columns, it often wants to go a long way beyond. Perl-ish one-liners are merely a extreme case of this. 3. Such long lines are often complex, which makes them hard to read and hard to debug. Opinion: we really shouldn't be encouraging people to write long complex lines of code. If a single line has more than a dozen method calls in it, it might be a tad too complex for one physical line regardless of how wide your monitor is :-) Splitting such complex expressions over multiple lines, or even multiple statements, can have advantages beyond merely keeping to the 79 column limit. It can often result in better code that is easier to understand, debug and maintain. 4. But one notable exception to this is the case where you have a long format string, often passed to "raise Exception", or print. They're rarely complicated or hard to read: at worst, substituting a few variables into a format string. These are often indented four or five levels deep, and they really are a pain-point. They're sometimes hard to split over multiple lines. And not only are they conceptually simple, but we rarely need to read them in detail. Its the surrounding code we need to read closely. (Raymond's post singles these kinds of lines out as especially problematic, and his observations agree with my experience.) Opinion: common sense should prevail here. If you have a line "raise ValueError(...)" which would reach 80 or even 90 characters, don't let PEP 8 alone tell you otherwise. It's just a rule, not a law of physics. We have rules so that you *think before you break them*. But if you have a more substantial code that exceeds 80 columns, that's a code smell and you ought to think long and hard before breaking it. Proposal: - keep PEP 8's current recommendation; - but remind people that the rule can be relaxed for lines that are conceptually simple, such as the "raise Exception(...)" pattern; - and also remind people that long *complex* lines are an anti-pattern. Such complex lines can be improved by splitting them over multiple lines, and should be. I know we try to think in hard limits. "If 79 is too short, then 90 or 100 or 150 or ..." I'm making a plea for the opposite: if you intend to break 80 columns, consider the line itself before breaking it. Don't just increase the limit. That effectively says "any amount of complexity is OK in a single line, so long as it remains below X columns". I'd rather people look at the line and decide "this is too complex, split it" or "it's just a format string (or whatever), let it be". -- Steven From raymond.hettinger at gmail.com Fri Feb 22 01:01:38 2019 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Thu, 21 Feb 2019 22:01:38 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: > On Feb 21, 2019, at 5:06 PM, Chris Barker via Python-ideas wrote: > > > class Frabawidget: > ... > @wozzle.setter > def (self, woozle): > if not (self.min_woozle < woozle < self.max_woozle): > raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") > self._wozzle = normalize(woozle) > > That's 103 chars long -- and very readable. But, is this that much worse? > > class Frabawidget: > ... > @wozzle.setter > def (self, woozle): > if not (self.min_woozle < woozle < self.max_woozle): > raise ValueError(f"Expected woozle to be between" > "{self.min_woozle} and {self.max_woozle}") > self._wozzle = normalize(woozle) > > (it IS harder to write, that's for sure) Yes, it's worse. You introduced twos bugs. First the space between the two fragments was lost. Second the f on the second f-string was dropped. I see these kinds of line-wrapping errors frequently. The bugs are CAUSED by the line length rule. Also, in the case of multi-line templates, there is no way to wrap them without getting very far from WYSIWYG: def run_diagnostics(location, system, test_engineer): ... if (failures): print(dedent(f'''\ There were {num_failures) anomalies detected in the {location} {system} at {event_time ::%I:%M:%S}}. These anomalies were classified as {level}. Further action is {'' if escalate else 'not'} recommended. ''') else: print(dedent(f'''\ A total of {num_test_cases} diagnostics were run in the {location} {system} as of {event_time::%I:%M:%S}}. No anomalies were detected and further action is not required. Test signed by {test_engineer.title()}. ... Raymond From pbergen at salesforce.com Fri Feb 22 02:38:22 2019 From: pbergen at salesforce.com (Philip Bergen) Date: Thu, 21 Feb 2019 21:38:22 -1000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: I agree that 80 columns produces too much artificial wrapping that is not more readable and harder to maintain. To that point see the bug in Chris Barker's email :) raise ValueError(f"Expected woozle to be between" "{self.min_woozle} and {self.max_woozle}") The missing f prefix on the second row is hard to spot. In my work we have settled on 100 characters. It's below the practical limitation where code review tools such as github pull request falls apart and still easily allows side by side editing. On Thu, Feb 21, 2019 at 3:20 PM wrote: > Send Python-ideas mailing list submissions to > python-ideas at python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request at python.org > > You can reach the person managing the list at > python-ideas-owner at 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: PEP 8 update on line length (pylang) > 2. Re: PEP 8 update on line length (Chris Barker) > 3. Re: Type hints for functions with side-effects and for > functions raising exceptions (Juancarlo A?ez) > > > > ---------- Forwarded message ---------- > From: pylang > To: Mike Miller > Cc: "python-ideas at python.org" > Bcc: > Date: Thu, 21 Feb 2019 17:32:12 -0500 > Subject: Re: [Python-ideas] PEP 8 update on line length > Some feedback: > > I code on a 13.5 inch laptop. I split my screen between my browser on the > left half and editor on the right half of the screen. > The 80 character suggestion has been helpful to me in reading code. > Otherwise I'd use up time with random horizontal scrolling. > > On Thu, Feb 21, 2019 at 4:11 PM Mike Miller > wrote: > >> >> On 2/21/19 10:53 AM, Paul Ferrell wrote: >> > I think the solution is for everyone to rotate their widescreen >> monitors 90? >> > into a really tall portrait mode. :) >> >> Yep, that's what I do, but would prefer a squarer monitor so I could get >> two >> windows side by side on that one also. My old 1600x1200 4:3 in portrait >> allowed >> that comfortably. 16:10 might. >> >> -Mike >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > > ---------- Forwarded message ---------- > From: Chris Barker > To: Python-Ideas > Cc: > Bcc: > Date: Thu, 21 Feb 2019 17:06:51 -0800 > Subject: Re: [Python-ideas] PEP 8 update on line length > On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger < > raymond.hettinger at gmail.com> wrote: > >> I concur. We now put expressions in f-strings and have assignment >> expressions that easily spill over 80 characters if one uses all but the >> most compact variable names. Comprehensions tend to make expressions >> longer. Queries and filters in Pandas also easily spill over. The 80 >> character limit pre-dates these evolutions of the language. >> > > >> In particular, the case where I most want to let people run with long >> lines is in forming messages to be displayed to a user. > > > I agree here -- and if it's messages (also comments - a twenty char > comment after a 70 char line should be fine!) then it's not part of the > logic of the code -- so not as bd if there is some spill off the screen for > those folks that do code on tablets ;-) Actually for me, the issue s comes > up when I'm showing code on a projector -- I use a huge font so folks in > the back can see) > > >> class Frabawidget: >> ... >> @wozzle.setter >> def (self, woozle): >> if not (self.min_woozle < woozle < self.max_woozle): >> raise ValueError(f"Expected woozle to be between >> {self.min_woozle} and {self.max_woozle}") >> self._wozzle = normalize(woozle) >> > > That's 103 chars long -- and very readable. But, is this that much worse? > > class Frabawidget: > ... > @wozzle.setter > def (self, woozle): > if not (self.min_woozle < woozle < self.max_woozle): > raise ValueError(f"Expected woozle to be between" > "{self.min_woozle} and {self.max_woozle}") > self._wozzle = normalize(woozle) > > (it IS harder to write, that's for sure) > > In doing code reviews, I see many fewer atrocities from long lines than I >> do from weird line-wraps and from variable names that have been >> over-shortened to make the line fit in 80 characters. To avoid these >> issues, my clients typically set their line limits at 90 or 100 > > > and yet the above example was 103 ... you do need a limit somewhere. > > I actually would really like the "limit" to depend on what the line is -- > that is, it's OK to go longer if it's essentially text -- message to the > user, comment, etc., rather than part of the code logic. > > In fact, now that I write that, I think I actually DO do that -- and even > add a # noqa sometimes so my linter will stop bugging me. A smart linter > would be nice here. > > PEP 8 is mostly about readability. However, the line length limit often >> seems to cause less readable code. >> > > So what do you suggest? simply increase the recommended line length? Or > would softening the language about extending it be enough? > > Maybe something along the lines of: > > A line length limit should be well defined for each project / organization > -- 80 char per line is safest for all users, but anything up to 100 is > appropriate if the team maintaining the code agrees. > > Raymond: As a core dev -- are suggesting extending the line limit for the > standard library? > > To all the folks quoting theory: let's be honest. Yes, really long lines > are harder to read, but the 80 char limit comes from old terminals, NOT any > analysis that somehow that is optimum for readability. > > -CHB > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > > > > ---------- Forwarded message ---------- > From: "Juancarlo A?ez" > To: Ivan Levkivskyi > Cc: Miikka Salminen , python-ideas < > python-ideas at python.org> > Bcc: > Date: Thu, 21 Feb 2019 21:20:38 -0400 > Subject: Re: [Python-ideas] Type hints for functions with side-effects and > for functions raising exceptions > > > On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi > wrote: > >> The idea about "checked exceptions" appeared several times in various >> places. I used to think that this would be hard to support for any >> realistic use cases. But now I think there may be a chance >> to turn this into a usable feature if one frames it correctly (e.g. the >> focus could be on user defined exceptions, rather than on standard ones, >> since there is no way we can annotate every function in typeshed). >> > > It's well documented how checked exceptions lead to bad code. That's why > C#, which came after Java, didn't include them. > > Exceptions may be logically thought as of part of the type of a method, > and of the type of the method's class, but that requires that the type > catches every exception that may be raised from the implementation and > either handles it, or translates it to one belonging to the type. It's a > lot of work, it's cumbersome, and it is fragile, as the exception handling > may need to change over minor implementation changes. If dependencies don't > treat the exceptions that may escape from them as part of the type, then > our own types will need to be changes every time a dependency changes its > implementation. > > The strategy of catching only exceptions of interest and letting others > pass produces less fragile and easier to test code. > > -- > Juancarlo *A?ez* > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > -- *Philip Bergen* P: +1(415)200-7340 *"Without data you are just another person with an opinion" -- W. Edwards Deming* -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Fri Feb 22 04:44:10 2019 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 22 Feb 2019 10:44:10 +0100 Subject: [Python-ideas] PEP 8 update on line length References: Message-ID: <20190222104410.029cb910@fsol> On Thu, 21 Feb 2019 11:59:56 -0800 Raymond Hettinger wrote: > > PEP 8 is mostly about readability. However, the line length limit often seems to cause less readable code. There are well-known typography rules around line length and readability, both on screen and in print. See e.g.: https://baymard.com/blog/line-length-readability It's not straight-forward how to apply these for code, because it is typically indented, with varying levels of indentation (should the indentation count towards character line length when making up a rule of thumb for readability?). However, there is a commonly held idea - with centuries of experience backing it - that overly long lines makes text or code less readable (look at your typical newspaper or magazine: it splits pages of text into a number of columns so as to limit line width). And "overly long" starts rather early, around 50-80 characters for non-indented text according to most typographers. For code, a 80 character limit is common, as are other limits such as 90 and 100. In any case, each project can customize their pep8 / flake8 settings easily. PEP 8 doesn't aim to be an inflexible standard (we don't even apply it mechanically in the stdlib). Regards Antoine. From jamtlu at gmail.com Wed Feb 20 15:16:55 2019 From: jamtlu at gmail.com (James Lu) Date: Wed, 20 Feb 2019 15:16:55 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190219095957.GD4465@ando.pearwood.info> <20190220001842.GI4465@ando.pearwood.info> Message-ID: <49CF4DEC-0AD3-412A-8A5E-DF3CF93FC803@gmail.com> A general rule of thumb is, if Python feels inconvenient or awkward, you?re doing something wrong. From pythonchb at gmail.com Fri Feb 22 11:50:17 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Fri, 22 Feb 2019 08:50:17 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <20190222043320.GQ4465@ando.pearwood.info> References: <20190222043320.GQ4465@ando.pearwood.info> Message-ID: > > > Chris, the convention to limit text to somewhere around 60-80 characters > predates old terminals by *literally centuries*. Not for code, it doesn?t? and centuries ago, there were other technical issues on play for papermaking, hand writing, and typesetting. > (And did they ever stop to wonder why those old terminals > standardized on 80 columns?) CRTs were small and low resolution? A 200 char line would have been very expensive back in the day, and I?m pretty sure the old tractor feed paper terminal I first learned to code on was a lot more than 80 char wide. But now that you mention it, I suspect the 80 char punch cards had an influence. How many of us still type on QWERTY keyboards? Even on a phone, like I am now. The point is that we conform to s lot of conventions without re-adding whether the original reasons for those conventions apply. And no one on this thread has cited a study about optimum line length for readability of code. I have no idea if that?s ever been done ? but that is the question at hand. ?Typesetters hundreds of years ago used less than 80 chars per line, so that?s what we should do for Python code now? is a pretty weak argument. > Go back and read the thread. I have read the thread. And Raymond made a pretty good argument for why, in some cases, a shorter line limit is a problem? and I have had much the same experience. and the nuisance value of splitting a conceptual > line of code over multiple physical lines. I think one key question is whether it?s a nuisance, or actually makes some code harder to read. > > 1. 79 characters is *very generous* for most lines of code; I?ve found a common exception for this is string literals and trailing comments. And I often prefer 80+ char trailing comments to an extra comment line. 2. When a single line goes beyond 80 columns, it often wants to go a > long way beyond. Often True, but I?ve found setting my linter to 95 char makes a big difference in my code > Opinion: we really shouldn't be encouraging people to write long complex > lines of code. Agreed ? but as you point out, those are often MUCH longer, so pushing the line limit to < 100 chars doesn?t really change that. 4. But one notable exception to this is the case where you have a long > format string, often passed to "raise Exception", ... > These are often indented four or five levels deep, and they really are a > pain-point. Oh yeah, that was Raymond?s point, and I concurred and emphasized it. > > Opinion: common sense should prevail here. If you have a line "raise > ValueError(...)" which would reach 80 or even 90 characters, don't let > PEP 8 alone tell you otherwise. Yup - the trick here is that it?s hard to define clearly in a style guide, and even harder in a linter. One issue with all this is that there?s been a move toward automated enforcement (or checking) of style. Which I think is an overall good thing, but then it?s hard to allow judgement as well. But if you have a more substantial code that exceeds 80 columns, that's > a code smell and you ought to think long and hard before breaking it. My reading of your points above is that the really smelly code is well over 80 chars, so having a slightly larger limit would work fine as well. Proposal: > > - keep PEP 8's current recommendation; As long as that includes the ? you can raise it to up to 100 char, sure :-) > > - but remind people that the rule can be relaxed for lines that are > conceptually simple, such as the "raise Exception(...)" pattern; It would be nice, if possible, to clearly define this relaxation. - and also remind people that long *complex* lines are an anti-pattern. > Such complex lines can be improved by splitting them over multiple > lines, and should be. Not sure that?s needed, but why not? > > That effectively says "any amount of complexity is OK in a single line, > so long as it remains below X columns". I'd rather people look at the > line and decide "this is too complex, split it" or "it's just a format > string (or whatever), let it be". Agreed ? you can have too much complexity in 80 char. Which is why I think the 80 char limit is about what fits on a screen, not complexity. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2QdxY4RzWzUUiLuE at potatochowder.com Fri Feb 22 12:23:51 2019 From: 2QdxY4RzWzUUiLuE at potatochowder.com (Dan Sommers) Date: Fri, 22 Feb 2019 11:23:51 -0600 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <20190222043320.GQ4465@ando.pearwood.info> References: <20190222043320.GQ4465@ando.pearwood.info> Message-ID: <966d730f-0435-27b7-945d-b701e8ff819f@potatochowder.com> On 2/21/19 10:33 PM, Steven D'Aprano wrote: > (And did they ever stop to wonder why those old terminals > standardized on 80 columns?) Punch cards? https://softwareengineering.stackexchange.com/questions/148677 There's an ensuing discussion regarding the history of the size/shape of the punch card, too. Dan From jfine2358 at gmail.com Fri Feb 22 12:37:46 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Fri, 22 Feb 2019 17:37:46 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <966d730f-0435-27b7-945d-b701e8ff819f@potatochowder.com> References: <20190222043320.GQ4465@ando.pearwood.info> <966d730f-0435-27b7-945d-b701e8ff819f@potatochowder.com> Message-ID: Raymond Hettinger posted a helpful example to this list. Here, I run his example, and a variant, through https://black.now.sh Raymond class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) black.py class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle): raise ValueError( f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}" ) self._wozzle = normalize(woozle) Raymond variant class Frabawidget: @wozzle.setter def wibble(self, woozle): if not (self.min_woozle < woozle < self.max_woozle < self.super_max_value) and do_this_or_that_(): raise ValueError(f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}") self._wozzle = normalize(woozle) black.py class Frabawidget: @wozzle.setter def wibble(self, woozle): if ( not ( self.min_woozle < woozle < self.max_woozle < self.super_max_value ) and do_this_or_that_() ): raise ValueError( f"Expected woozle to be between {self.min_woozle} and {self.max_woozle}" ) self._wozzle = normalize(woozle) (By the way, I had to add the 'wibble' to the code above, to avoid a syntax error.) -- Jonathan From rosuav at gmail.com Fri Feb 22 13:54:48 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 23 Feb 2019 05:54:48 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: On Sat, Feb 23, 2019 at 5:32 AM Juancarlo A?ez wrote: > On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico wrote: >> >> On Fri, Feb 22, 2019 at 2:27 PM Juancarlo A?ez wrote: >> > Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException. >> > >> >> That assumes atomicity. If you want an atomic "replace top of stack" >> that can never raise StackFullException, it's probably best to express >> it as stack.replacetop(x) rather than having something that might be >> interrupted. > > Ah! What to do with an exception in a concurrent context? Abort, or retry after a while? You mean in a situation where another thread might be pushing/popping on the same stack? That's up to you. Exception handling works exactly the same way with multiple threads as it does with a single thread; each context has a call stack. Things are a bit more complicated with other forms of concurrency, but at the point where there is an execution context again, that's where exceptions can start bubbling again. That's how generators work, for instance. ChrisA From apalala at gmail.com Fri Feb 22 13:32:45 2019 From: apalala at gmail.com (=?UTF-8?Q?Juancarlo_A=C3=B1ez?=) Date: Fri, 22 Feb 2019 14:32:45 -0400 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: Message-ID: On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico wrote: > On Fri, Feb 22, 2019 at 2:27 PM Juancarlo A?ez wrote: > > Then, if exceptions are going to be part of a type, there should be a > way to express the semantics of them (like in Eiffel), so > stack.pop();stack.push(x) doesn't have to catch StackFullException. > > > > That assumes atomicity. If you want an atomic "replace top of stack" > that can never raise StackFullException, it's probably best to express > it as stack.replacetop(x) rather than having something that might be > interrupted. > Ah! What to do with an exception in a concurrent context? Abort, or retry after a while? > People do dumb things with exceptions, yes. Why does this mean that > they are bad? I don't understand this. Exception handling (and stack > unwinding) gives an easy and clear way to refactor code without having > to daisychain error handling everywhere. How is throwing that away > going to help people write better code? > For programs that are recursive or multi-layered, exceptions are a clean and efficient way to unwind. This PEG parser generator I wrote was made possible because Python exceptions are semantically clean and very efficient: https://github.com/neogeny/TatSu/blob/master/tatsu/contexts.py > But then, Golang also decided that Unicode wasn't necessary, and we > should all deal with UTF-8 encoded byte sequences instead of text > strings, so I'm fairly sure there are no ten foot barge poles long > enough for me to touch it with. There are languages that have problems > because of history (*cough*JavaScript*cough*), but for a new language > to make multiple poor decisions just means it's one to avoid. > The quest for a programming language in which _"anyone"_ can program, _without_ making mistakes, has never ended, and probably never will. "Alexa! Please write the software for a new Internet email system that overcomes the limitations of the current one!" Sometimes staying away is not an option. -- Juancarlo *A?ez* -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Fri Feb 22 16:10:04 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 23 Feb 2019 10:10:04 +1300 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: <20190222043320.GQ4465@ando.pearwood.info> Message-ID: <5C70652C.7050007@canterbury.ac.nz> Christopher Barker wrote: > (And did they ever stop to wonder why those old terminals > standardized on 80 columns?) Probably because IBM decided on 80 columns for their punched cards. And that probably didn't have anything to do with a readable width for text. Nobody used computers for word processing back then. In fact punched cards predate computers altogether, originally being developed for electromechanical accounting and record keeping machines. > I?m > pretty sure the old tractor feed paper terminal I first learned to code > on was a lot more than 80 char wide. Line printers were traditionally 120 chars wide, but again that had nothing to do with text. It was so that accountants could print reports with a ridiculously large number of columns of figures. > How many of us still type on QWERTY keyboards? Even on a phone, like I > am now. Once you're used to qwerty, anything else is a nuisance, even if you're not touch typing on it. A place I park at recently installed machines you enter your car's license number into. The keyboard has the letters in alphabetical order, presumably because someone thought it would be "easier". But nowadays I suspect it just makes it harder for most people! > ?Typesetters hundreds of years ago used less than 80 chars per line, so > that?s what we should do for Python code now? is a pretty weak argument. But that's not the entire argument -- the point it is that typesetters had the goal of making lines of text readable, which is similar (if not quite the same) as the goal of making lines of program code readable. It's a lot closer than, for example, the goal of fitting in an accountant's spreadsheet. > Agreed ? you can have too much complexity in 80 char. Which is why I > think the 80 char limit is about what fits on a screen, not complexity. I would say it the other way around. Once you've reduced the complexity of a line to something a human can handle, *most* of the time 80 chars is enough. There will be exceptions, but as long as the exceptions are rare, making your editing window any wider will mostly just waste screen space. -- Greg From klahnakoski at mozilla.com Fri Feb 22 17:13:17 2019 From: klahnakoski at mozilla.com (Kyle Lahnakoski) Date: Fri, 22 Feb 2019 17:13:17 -0500 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On 2019-02-21 03:09, Christopher Barker wrote: > > But yes, there is no (easy) way to distinguish an Exception raised by the function you called, and one raised somewhere deeper that. > > And I have been bitten by that more than once. It makes "Easier to ask forgiveness than permission" kind of tricky. > And Exception handling is messy -- the point made by the OP, I'm not sure there's a better way to do it. It seems to me that exception *classes* are hardly ever required. If two methods raise the same exception type, then I contend that they are actually throwing two different types of errors (as evidenced by the difference in the message). Instead, I suggest every method emits its own exception type. By demanding support for a plethora of exception types, at least as many as there are methods, then we may have a different way of looking at exceptions: The first conclusion is, it is too expensive to make classes for every exception type, rather, exception type should be defined by the message. Exception handling is messy. I find most of my Python methods look like: ??? | def my_method(): ??? |???? try: ??? |???????? # do something ??? |???? except Exception as e: ??? |???????? error("some description", cause=e) I am not using Python3 everywhere yet, so maybe it should read like: ??? | def my_method(): ??? |???? try: ??? |???????? # do something ??? |???? except Exception as e: ??? |???????? raise Exception("some description") from e Let me call this pattern the Catch-It-Name-It-Chain-It-Raise-It (CNCR) pattern ? There are a few reasons for this. 1. I can add runtime values to the exception so I get a better sense of the program state without going to the debugger:? `error("some description", {"url": url}, cause=e)` 2. I prevent exception leakage; I have no idea the diversity of exceptions my code can raise, so I CNCR. 3. Every exception is it's own unique type; I can switch on the message if I want (I rarely do this, but it happens, see below) Can Python provide better support for the CNCR pattern? If it is lightweight enough, maybe people will use it, and then we can say something useful about the (restricted) range of exceptions coming from a method: A context manager, a `with` block, could do this: ? ??? | def my_method(): ??? |???? with Explanation("some description"): ??? |???????? # do something I propose a simple line, which effectively defines a try block to the end of the current code block. Call it the `on-raises` syntax: ??? | def my_method(): ??? |???? on Exception raises "some description" ??? |???? # do something It is better than the `with` block because: * it does not put code in the happy path * it has less indentation * we can conclude "some description" is the only exception raised by this method ? The `on-raises` need not start at the beginning of a code block, but then we can say less about what exceptions come out of `my_method`: ??? | def my_method(): ??? |???? # no exception checks here ??? |???? on Exception raises "some description" ??? |???? # do something Since `on-raises` can be used in any code block, we can save some indentation. Instead of ??? | def my_method(): ??? |???? with some_file: ??? |???????? try: ??? |???????????? # do something ??? |???????? except Exception as e: ??? |???????????? raise Exception("some description") from e we have ??? | def my_method(): ??? |???? with some_file: ??? |???????? on Exception raises "some description" ??? |???????? # do something of course we can have nested `on-raises`, ??? | def my_method(): ??? |???? on Exception raises "bigger problem" ??? |???? with some_file: ??? |???????? on Exception raises "some description" ??? |???????? # do something Plus we know only "bigger problem" exceptions can be raised. The above is the same as: ??? | def my_method(): ??? |???? try: ??? |???????? with some_file: ??? |???????????? try: ??? |???????????????? # do something ??? |???????????? except Exception as e: ??? |???????????????? raise Exception("some description") from e ??? |???? except Exception as e: ??? |???????? raise Exception("bigger problem") from e in the rare case we actually want to deal with an exception, we revert back to trusty old try/except: ??? | def my_other_method(): ??? |???? on Exception raises "some other description" ??? |???? try: ??? |???????? my_method() ??? |???? except "some description" as e: ??? |???????? # I know how to handle this case ??? |???????? return which is the same as: ??? | def my_other_method(): ??? |???? try: ??? |???????? my_method() ??? |???? except Exception as e: ??? |???????? if "some description" in e: ??? |???????????? # I know how to handle this case ??? |???????????? return ??? |???????? error("some other description", cause=e) From rosuav at gmail.com Fri Feb 22 17:20:35 2019 From: rosuav at gmail.com (Chris Angelico) Date: Sat, 23 Feb 2019 09:20:35 +1100 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: On Sat, Feb 23, 2019 at 9:14 AM Kyle Lahnakoski wrote: > Let me call this pattern the Catch-It-Name-It-Chain-It-Raise-It (CNCR) > pattern > > There are a few reasons for this. > > 1. I can add runtime values to the exception so I get a better sense of > the program state without going to the debugger: `error("some > description", {"url": url}, cause=e)` > 2. I prevent exception leakage; I have no idea the diversity of > exceptions my code can raise, so I CNCR. > 3. Every exception is it's own unique type; I can switch on the message > if I want (I rarely do this, but it happens, see below) > > Can Python provide better support for the CNCR pattern? If it is > lightweight enough, maybe people will use it, and then we can say > something useful about the (restricted) range of exceptions coming from > a method: The CNCR pattern, if used repeatedly, will quickly create a long chain of exceptions, where each exception represents one function call. Python already has very good support for seeing the function call history that led to the exception - it's called a traceback. You even get the full function locals as part of the exception object... and it requires no code whatsoever! Simply allowing exceptions to bubble up will have practically the same benefit. ChrisA From apalala at gmail.com Fri Feb 22 17:23:31 2019 From: apalala at gmail.com (=?UTF-8?Q?Juancarlo_A=C3=B1ez?=) Date: Fri, 22 Feb 2019 18:23:31 -0400 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5C70652C.7050007@canterbury.ac.nz> References: <20190222043320.GQ4465@ando.pearwood.info> <5C70652C.7050007@canterbury.ac.nz> Message-ID: On Fri, Feb 22, 2019 at 5:10 PM Greg Ewing wrote: > I would say it the other way around. Once you've reduced the complexity > of a line to something a human can handle, *most* of the time 80 chars > is enough. > +1 It has been known for a very long time. These are *old *books that talk about *refactoring* (the word wasn't used then) of complex code (assigning subexpressions to variables, or extracting code into functions, reverting conditionals, etc.), not for line length, but for understandability, yet resulting nevertheless in much shorter lines: - Software Tools (also Software Tools in Pascal), Kernighan and Plauger, 1976 https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X - Code Complete (also the second edition), Steve Mc Connell, 1993, https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X I do make an exception in that after taking 8 spaces of indentation to write the implementation of a method in Python, the sweet spot is more around 100 chars. -- Juancarlo *A?ez* -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.dubois at zaclys.net Sat Feb 23 05:42:55 2019 From: alexandre.dubois at zaclys.net (Alexandre Dubois) Date: Sat, 23 Feb 2019 11:42:55 +0100 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5C70652C.7050007@canterbury.ac.nz> References: <20190222043320.GQ4465@ando.pearwood.info> <5C70652C.7050007@canterbury.ac.nz> Message-ID: <5d49f2c4-2cdf-41ec-bdb5-63f3b3befb8b@zaclys.net> Hi, Le 22/02/2019 ? 22:10, Greg Ewing a ?crit?: > > I would say it the other way around. Once you've reduced the complexity > of a line to something a human can handle, *most* of the time 80 chars > is enough. > I totally agree with Greg Ewing on that point. The only time when line length is a hinder by itself to me is when I can't split the windows side by side and fit both the lines of the code and it's unit-tests. And this case never happen alone as the "I can't describe easily what this line of code does" is a way bigger problem than the line length. Alexandre Dubois --- L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le logiciel antivirus Avast. https://www.avast.com/antivirus From tritium-list at sdamon.com Sun Feb 24 23:45:49 2019 From: tritium-list at sdamon.com (Alex Walters) Date: Sun, 24 Feb 2019 23:45:49 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5C70652C.7050007@canterbury.ac.nz> References: <20190222043320.GQ4465@ando.pearwood.info> <5C70652C.7050007@canterbury.ac.nz> Message-ID: <009a01d4ccc4$fb570ef0$f2052cd0$@sdamon.com> > Probably because IBM decided on 80 columns for their punched cards. > And that probably didn't have anything to do with a readable width > for text. Nobody used computers for word processing back then. > In fact punched cards predate computers altogether, originally > being developed for electromechanical accounting and record keeping > machines. > Textile looms, actually. Neither here nor there about the length of lines in PEP8 but an interesting factoid none the less. IBM (and possibly others) took punch cards from looms. On the subject of the 79 character line limit, its come up a lot in the past. * PEP-8 is the guidelines for the standard library that python-dev doesn't even strictly enforce. While it makes a decent starting point for your own project guidelines, change anything you want. * 79 characters is a reasonable ball-park figure for how long a line should be for most people * Going much above 79 characters is an indication of code smell * No matter what number you come up with, someone is going to be upset. There is no way to win in changing the guideline. PEP-8 is not a universal truth, or even a standard, we really shouldn't be treating it like it is. From raymond.hettinger at gmail.com Mon Feb 25 00:21:42 2019 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Sun, 24 Feb 2019 21:21:42 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5C70652C.7050007@canterbury.ac.nz> References: <20190222043320.GQ4465@ando.pearwood.info> <5C70652C.7050007@canterbury.ac.nz> Message-ID: <5C240328-4543-454B-8C78-5C4DE8D1CFDD@gmail.com> > On Feb 22, 2019, at 1:10 PM, Greg Ewing wrote: >> ?Typesetters hundreds of years ago used less than 80 chars per line, so that?s what we should do for Python code now? is a pretty weak argument. > > But that's not the entire argument -- the point it is that typesetters > had the goal of making lines of text readable, which is similar (if not > quite the same) as the goal of making lines of program code readable. > It's a lot closer than, for example, the goal of fitting in an > accountant's spreadsheet. The issue with reference to typesetter rules is that they were targeted at blocks of prose rather than heavily nested hanging indents with non-trivial string literals or a dotted attribute notation. Typesetters were also dealing with fixed page widths and need to leave gutter space for binding. The "rules" aren't comparable at all. > I would say it the other way around. Once you've reduced the complexity > of a line to something a human can handle, *most* of the time 80 chars > is enough. That would make sense if we started at column 0; however, if you have your prefix your thoughts with something like ''' class TestRemote(unittest.TestCase): def test_heartbeat(self): ... self.assertIsInstance(... ''' then the meant of the part "a human can handle" starts at column 30. Then if you need good variable names and/or have to module.function prefixes, there is sometimes little to left to work with. Raymond From mertz at gnosis.cx Mon Feb 25 00:47:31 2019 From: mertz at gnosis.cx (David Mertz) Date: Mon, 25 Feb 2019 00:47:31 -0500 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <5C240328-4543-454B-8C78-5C4DE8D1CFDD@gmail.com> References: <20190222043320.GQ4465@ando.pearwood.info> <5C70652C.7050007@canterbury.ac.nz> <5C240328-4543-454B-8C78-5C4DE8D1CFDD@gmail.com> Message-ID: As a human, and one who reads and writes code even, I know that MY ability to understands the meaning of a line of code starts to plummet when it reaches about 65-70 characters in length. Yes, of course there are some "it depends" caveats that make some lines easier and some harder. But an 80 characters "limit" is an excellent rule of thumb, as long as most coders usually "err" on the short side. My brain is a lot like those of people whom typesetters have typeset for for hundred of years, and whom scribes have written for for thousands. It's easy to be sophistical and discover that code is so very much different that roles of intelligibility don't apply. It's not though, and they do still. Or maybe everyone else in the thread is simply smarter and better able to handle complexity than I am. More power to you, but that definitely doesn't feel like "computer programming for everyone." If you want to write 100 or 120 characters lines, Python won't complain, but you've walled off your code from me as a potential reader of it. On Mon, Feb 25, 2019, 12:25 AM Raymond Hettinger < raymond.hettinger at gmail.com> wrote: > > > > On Feb 22, 2019, at 1:10 PM, Greg Ewing > wrote: > > >> ?Typesetters hundreds of years ago used less than 80 chars per line, so > that?s what we should do for Python code now? is a pretty weak argument. > > > > But that's not the entire argument -- the point it is that typesetters > > had the goal of making lines of text readable, which is similar (if not > > quite the same) as the goal of making lines of program code readable. > > It's a lot closer than, for example, the goal of fitting in an > > accountant's spreadsheet. > > > The issue with reference to typesetter rules is that they were targeted at > blocks of prose rather than heavily nested hanging indents with non-trivial > string literals or a dotted attribute notation. Typesetters were also > dealing with fixed page widths and need to leave gutter space for binding. > > The "rules" aren't comparable at all. > > > > I would say it the other way around. Once you've reduced the complexity > > of a line to something a human can handle, *most* of the time 80 chars > > is enough. > > That would make sense if we started at column 0; however, if you have your > prefix your thoughts with something like > > ''' > class TestRemote(unittest.TestCase): > def test_heartbeat(self): > ... > self.assertIsInstance(... > ''' > > then the meant of the part "a human can handle" starts at column 30. Then > if you need good variable names and/or have to module.function prefixes, > there is sometimes little to left to work with. > > > Raymond > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From turnbull.stephen.fw at u.tsukuba.ac.jp Mon Feb 25 04:37:39 2019 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Mon, 25 Feb 2019 18:37:39 +0900 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: <009a01d4ccc4$fb570ef0$f2052cd0$@sdamon.com> References: <20190222043320.GQ4465@ando.pearwood.info> <5C70652C.7050007@canterbury.ac.nz> <009a01d4ccc4$fb570ef0$f2052cd0$@sdamon.com> Message-ID: <23667.46947.359716.305549@turnbull.sk.tsukuba.ac.jp> Alex Walters writes: > There is no way to win in changing the guideline. IMO this is true, despite the comment below: > PEP-8 is not a universal truth, or even a standard, we really > shouldn't be treating it like it is. Unfortunately, it's not us (at least, I don't think it is), and it's not our choice. Despite repeated warnings on the lists and even in the PEP that this is specific to the Python standard library, there are a lot of projects that choose to use the pep8 and flake8 utilities to more or less enforce PEP 8 as a standard. I believe the OP was in that situation, and it usually comes up when we have these discussions. They want us to take leadership in enforcing their standard on the rest of the world. But I don't see what's in it for us, given how divided we are on the issue. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull at sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN From jfine2358 at gmail.com Mon Feb 25 04:49:59 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Mon, 25 Feb 2019 09:49:59 +0000 Subject: [Python-ideas] PEP 8 and long string literals Message-ID: I've started this thread, because I think long string literals are somewhat special, and may have an easy resolution. According to PEP 8 a good reason to ignore the line-length (or any other) guideline is that "applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP." PEP 8 also says "Limit all lines to a maximum of 79 characters." So perhaps it is enough, for long string literals, to add a note to PEP 8: When sensible to do so, lines containing a long string literal can exceed this length. It might also help to add to PEP 8 some Programming Recommendations for Long String Literals. (PEP 8 already has recommendations for Function and Variable Annotations.) Finally, tools such as pep8 and pylint would need some changes, to treat differently lines that contain a long string constant. -- Jonathan From songofacandy at gmail.com Mon Feb 25 05:04:55 2019 From: songofacandy at gmail.com (INADA Naoki) Date: Mon, 25 Feb 2019 19:04:55 +0900 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: I think long URL in comment or docstring is good reason to ignore line length limit. But I'm not sure about general long string literals. -- INADA Naoki From jfine2358 at gmail.com Mon Feb 25 05:23:47 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Mon, 25 Feb 2019 10:23:47 +0000 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: On Mon, Feb 25, 2019 at 10:05 AM INADA Naoki wrote: > I think long URL in comment or docstring is good reason to ignore > line length limit. A very good point. We can't banish long URLs from the Internet, because they violate PEP 8. > But I'm not sure about general long string literals. I hope programmers would be sensible in their use of long string literals (as with their choice of variable names). However, I don't think this can be reliable machine checked, with the tools we presently have. Machines find it hard to determine programmer intent, except via a formal language. -- Jonathan From tjol at tjol.eu Mon Feb 25 07:04:16 2019 From: tjol at tjol.eu (Thomas Jollans) Date: Mon, 25 Feb 2019 13:04:16 +0100 Subject: [Python-ideas] Support localization of unicode descriptions In-Reply-To: References: Message-ID: <8fe32a43-cb0a-827b-b7c3-50fc66ef0b89@tjol.eu> On 10/07/2018 23.20, David Mertz wrote: > The problem with non-canonical translations of the Unicode character > names is that there is not one unique possible rendering into language > X. Equally, I could find synonyms in general English for the names, but > one would be official, the others at best informally clarifying. Let's not forget that some official names of unicode symbols are either misleading or entirely wrong, but cannot be changed. See e.g. https://www.unicode.org/notes/tn27/tn27-4.html > For informational purposes I think it's great to have a third party > project to find out "Unicode character named 'Something In English' is > roughly translated as in your native language." But it's hard > to see how an unofficial loose cross-language dictionary should be party > of the standard library. > > On Tue, Jul 10, 2018, 5:11 PM Terry Reedy > wrote: > > On 7/10/2018 4:45 AM, Pander wrote: > > > This is a third party initiative. The translations are contributed by > > volunteers. I have talked with Python core developers and they > suggested > > to post this here, as it is for them out of scope for Python std lib. > > Python-ideas list is for discussion of python and the stdlib library. > This is not a place for prolonged discussion of pypi projects. > It *is* a place to discuss adding a hook that can be used to access > translations. > > There are both official doc translations, accessible from the official > doc pages, and others that are independent.? The official ones, at > least, are discussed on the doc-sig list > https://mail.python.org/mailman/listinfo/doc-sig > There are currently 7 languages and coordinators listed at > https://devguide.python.org/experts/#documentation-translations > 4 have progressed far enough to be listed in the drop-down box on > https://docs.python.org/3/ > > I should think that these people should be asked if they want to be > involved with unicode description translations.? They should certainly > have some helpful advice. > > The description vocabulary is rather restricted, so a word translation > dictionary should be pretty easy.? For at least for some languages, it > should be possible to generate the 200000 description translations from > this. The main issues are word order and language-dependent 'word' > units.? Hence, the three English words "LATIN SMALL LETTER" become two > words in German, 'LATEINISCHER KLEINBUCHSTABE', versus three words in > Spanish, but in reverse order, 'LETRA PEQUE?A LATINA'.? It is possible > that the doc translators already uses translation software that deal > with these issues. > > -- > Terry Jan Reedy From arj.python at gmail.com Mon Feb 25 11:11:55 2019 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Mon, 25 Feb 2019 20:11:55 +0400 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: saw that today 80 Characters per Line Is a Standard Worth Sticking to Even Today https://dev.to/nickjj/80-characters-per-line-is-a-standard-worth-sticking-to-even-today-26kk Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Tue, 19 Feb 2019, 08:38 Simon, wrote: > Hello, > > I'd like to propose an update to PEP8. Indeed, the 80 characters per line > guideline is, I feel, outdated. > > I understand the need for it, back when monitors were small, and everyone > coded on terminals, but nowadays, I feel like that guideline is more of a > hinderance, and that it promotes poor code. > > Indeed, people abiding by this rule tend to choose shorter variable names, > reduce the amount of indentation, and other tricks to just keep the > character count under 80. I think a 100 or even 120 suggested characters > per line count is much more realistic by today's standards. It still allow > for the code to be completely displayed, even on just half of a screen. > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klahnakoski at mozilla.com Mon Feb 25 13:00:32 2019 From: klahnakoski at mozilla.com (Kyle Lahnakoski) Date: Mon, 25 Feb 2019 13:00:32 -0500 Subject: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions In-Reply-To: References: <20190219231247.GE4465@ando.pearwood.info> Message-ID: <06c98b31-6d21-d4a6-498a-da709e488f84@mozilla.com> On 2019-02-22 17:20, Chris Angelico wrote: > On Sat, Feb 23, 2019 at 9:14 AM Kyle Lahnakoski wrote: >> Can Python provide better support for the CNCR pattern? If it is >> lightweight enough, maybe people will use it, and then we can say >> something useful about the (restricted) range of exceptions coming from >> a method: > The CNCR pattern, if used repeatedly, will quickly create a long chain > of exceptions, where each exception represents one function call. > Python already has very good support for seeing the function call > history that led to the exception - it's called a traceback. You even > get the full function locals as part of the exception object... and it > requires no code whatsoever! Simply allowing exceptions to bubble up > will have practically the same benefit. I like your point that the exception chain is long, and similar to the stack: I do find that in practice. This may indicate there is an optimization in how CNCR can be handled:? Maybe instantiation of CNCR exceptions can be deferred to the point where an exception handler actually does something beyond CNCR, if ever. I also agree, with a debugger at hand, we can inspect the stack trace. We can also write code that reflects on the method names in the stack trace to figure out how to handle an exception. But, I am concerned that stack trace inspection is brittle because methods can be renamed and refactored.? Also, the CNCR pattern is not 1-1 with methods, there can be more than one type of CNCR exception emitted from a method.? Methods could be split, so each only throws one type of exception; and then the stack trace would suffice; but that brings us back to brittle: A split method may be accidentally merged for clarity at a later time. We should also consider what happens in the case that an exception chain is not handled: It may be printed to the log: We can not reasonably print all the locals; there are many, some do not serialize, and some are sensitive.? CNCR is being explicit about what locals(), if any, are important. From dwblas at gmail.com Mon Feb 25 13:06:34 2019 From: dwblas at gmail.com (David B) Date: Mon, 25 Feb 2019 10:06:34 -0800 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: I generally break them up and then use "".join() as that is "most readable" IMHO. The same is true for SQL queries. On 2/25/19, Jonathan Fine wrote: > On Mon, Feb 25, 2019 at 10:05 AM INADA Naoki > wrote: >> I think long URL in comment or docstring is good reason to ignore >> line length limit. > > A very good point. We can't banish long URLs from the Internet, > because they violate PEP 8. > >> But I'm not sure about general long string literals. > > I hope programmers would be sensible in their use of long string > literals (as with their choice of variable names). However, I don't > think this can be reliable machine checked, with the tools we > presently have. Machines find it hard to determine programmer intent, > except via a formal language. > > -- > Jonathan > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- With the simplicity of true nature, there shall be no desire. Without desire, one's original nature will be at peace. And the world will naturally be in accord with the right Way. Tao Te Ching From mertz at gnosis.cx Mon Feb 25 14:20:27 2019 From: mertz at gnosis.cx (David Mertz) Date: Mon, 25 Feb 2019 14:20:27 -0500 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: I find the main pain point of line width limits to be string literals that call out to some *other* code-like thing. Long URLs, user messages, and long SQL are three common examples. It's actually less an issue with SQL since that is itself more readable across multiple lines, plus SQL itself doesn't care about newlines embedded. So just using triple-quoted strings works best there. However, sometimes it's just a quick one-liner SQL I want to include, but that can easily grow longer than 80 characters (or really even 50 chars if the SQL is being assigned to something inside some nested logic, or being an argument to a function call). URLs can get long, and are whitespace sensitive. I wrote something like this just today: url = (f'{URL_BASE}' f'&arg1={row["column_name_1"]}' f'&something_else={1+row["that value"]}' f'&more_args={USER_ID}' f'&some_other_stuff={translate[row["foo"]]}' f'&yep_this={row["foo"]}' f'&arg17=123456') I don't think that's terrible, and it's a lot nicer to be able to visually separate what are really arguments to a REST call. But it's definitely super-easy to mess up this sort of thing, including by letting a little whitespace sneak in where I don't want it. But if the URL wasn't quite so convoluted (this example is pretty directly taken from a real thing today, just a few names munged to protect the client :-)), I might want it on one line. And I'd probably want my linters to stop nagging me about the fact I do that. However, what I care about more than that is my editor. It would be really nice if my editor provided something like "vertical folding" for things like this. I do not know of any editors that do that, but it would be easy to imagine. E.g. I might have an editor display: url = f'{URL_BASE}&arg1={row["column_*(..93 chars..)*rg17=123456' Does anyone know of editors that do that sort of thing? Obviously, you'd need some way to fold/unfold the hidden text. But for many purposes, the first and last few characters probably convey the purpose of the line. On Mon, Feb 25, 2019 at 4:53 AM Jonathan Fine wrote: > I've started this thread, because I think long string literals are > somewhat special, and may have an easy resolution. > > According to PEP 8 a good reason to ignore the line-length (or any > other) guideline is that "applying the guideline would make the code > less readable, even for someone who is used to reading code that > follows this PEP." > > PEP 8 also says "Limit all lines to a maximum of 79 characters." > > So perhaps it is enough, for long string literals, to add a note to > PEP 8: When sensible to do so, lines containing a long string literal > can exceed this length. > > It might also help to add to PEP 8 some Programming Recommendations > for Long String Literals. (PEP 8 already has recommendations for > Function and Variable Annotations.) > > Finally, tools such as pep8 and pylint would need some changes, to > treat differently lines that contain a long string constant. > > -- > Jonathan > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfine2358 at gmail.com Mon Feb 25 14:50:36 2019 From: jfine2358 at gmail.com (Jonathan Fine) Date: Mon, 25 Feb 2019 19:50:36 +0000 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: Hi David Thank you for sharing your experience. I'd be most grateful if you could tell us, are you happy with the interpretation and additions I've suggested for PEP 8? And the revisions to pep8 and other linting tools? Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at krypto.org Mon Feb 25 15:00:50 2019 From: greg at krypto.org (Gregory P. Smith) Date: Mon, 25 Feb 2019 12:00:50 -0800 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: On Mon, Feb 25, 2019 at 2:05 AM INADA Naoki wrote: > I think long URL in comment or docstring is good reason to ignore > line length limit. > Yep, that's what we do in the yapf autoformatter. There's good reason too, source viewers and editors linkify URLs, if you break them across strings to fit within a line length limit, you get a broken partial url. It also makes searching a codebase for references to specific identifiers much more difficult if you've broken up their value at arbitrary points. There are other examples for this such as allowing trailing line comments for pylint, type checkers, etc. to go beyond 80 columns. See the Exceptions in https://google.github.io/styleguide/pyguide.html#32-line-length for what make good practical examples. I'm not convinced that codifying this in PEP-8 makes sense though unless we see this happening within the Python standard library code itself (the purpose of pep-8). PEP-8 is not trying to be a style guide for all Python users, just a stdlib style guide that happens to serve a base from which to build upon. -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Mon Feb 25 17:08:48 2019 From: mertz at gnosis.cx (David Mertz) Date: Mon, 25 Feb 2019 17:08:48 -0500 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: I've sort of lost the threads about who recommends what. I do not think that PEP8 needs to include a sentence like "Better tooling would be really cool" ... notwithstanding that I think that is a true sentence. On Mon, Feb 25, 2019 at 2:50 PM Jonathan Fine wrote: > Hi David > > Thank you for sharing your experience. > > I'd be most grateful if you could tell us, are you happy with the > interpretation and additions I've suggested for PEP 8? > > And the revisions to pep8 and other linting tools? > > Jonathan > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pythonchb at gmail.com Mon Feb 25 21:01:08 2019 From: pythonchb at gmail.com (Christopher Barker) Date: Mon, 25 Feb 2019 18:01:08 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: > saw that today > > 80 Characters per Line Is a Standard Worth Sticking to Even Today > https://dev.to/nickjj/80-characters-per-line-is-a-standard-worth-sticking-to-even-today-26kk > Same arguments made in this thread. I noticed that most of the comments were from folks disagreeing:-) Anyway, the only point to have UNH this discussion on this list is to suggest changes to PEP8. And clearly there is no consensus to increase the line length in the Style guide. So I would like to propose the softening of the language a bit as I proposed earlier in this thread, and other than that call it done. Here?s what I wrote: We could reword: """ Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters. """ To be a bit less harsh -- that is, change the clause: "For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay ..." To maybe just "For code maintained by a team that can reach agreement on this issue, it is okay ..." -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython -------------- next part -------------- An HTML attachment was scrubbed... URL: From arj.python at gmail.com Mon Feb 25 21:20:04 2019 From: arj.python at gmail.com (Abdur-Rahmaan Janhangeer) Date: Tue, 26 Feb 2019 06:20:04 +0400 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: i thought it interesting as it presented a non py's view of things (web dev) for the 80 chars length. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius -------------- next part -------------- An HTML attachment was scrubbed... URL: From turnbull.stephen.fw at u.tsukuba.ac.jp Tue Feb 26 02:32:37 2019 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Tue, 26 Feb 2019 16:32:37 +0900 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: References: Message-ID: <23668.60309.873111.908900@turnbull.sk.tsukuba.ac.jp> David Mertz writes: > However, what I care about more than that is my editor. It would be really > nice if my editor provided something like "vertical folding" for things > like this. I do not know of any editors that do that, but it would be easy > to imagine. E.g. I might have an editor display: > > url = f'{URL_BASE}&arg1={row["column_*(..93 chars..)*rg17=123456' > > Does anyone know of editors that do that sort of thing? Obviously, > you'd need some way to fold/unfold the hidden text. But for many > purposes, the first and last few characters probably convey the > purpose of the line. You may not like my answer: Emacs does several kinds of hiding text. They're not exactly what you ask for, of course, but the tools are definitely there. The only automatic hiding features I use are truncate-lines mode, which as you might guess hides the tail of the line by default, but also scrolls only that line if point moves into the hidden tail (as many browsers do in their address bars), and outline mode, which has a couple of ways to tweak display (hide non-heading text, hide subheadings, do either locally or globally). I don't know who maintains python-mode, but they might be interested in your suggestion if you're interested in an Emacs feature. Whoever maintains python-mode is exceptionally open to wacky (ie, contra GNUish orthodoxy) ideas, I must say. It's the only mode I use where RET is bound to newline-and-indent instead of newline, for example. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull at sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN From viniciuscarqueijo at gmail.com Tue Feb 26 05:52:09 2019 From: viniciuscarqueijo at gmail.com (Vinicius Mesel) Date: Tue, 26 Feb 2019 07:52:09 -0300 Subject: [Python-ideas] PEP 8 and long string literals In-Reply-To: <23668.60309.873111.908900@turnbull.sk.tsukuba.ac.jp> References: <23668.60309.873111.908900@turnbull.sk.tsukuba.ac.jp> Message-ID: If you use Atom (http://atom.io), you can use the default functionality called Wrap Guide. The wrap guide is fully configurable to your needs on different line lengths (https://github.com/atom/wrap-guide). The example on the doc shows 4 wrap guides: 'wrap-guide': 'columns': [72, 80, 100, 120] On Tue, Feb 26, 2019 at 4:32 AM Stephen J. Turnbull < turnbull.stephen.fw at u.tsukuba.ac.jp> wrote: > David Mertz writes: > > > However, what I care about more than that is my editor. It would be > really > > nice if my editor provided something like "vertical folding" for things > > like this. I do not know of any editors that do that, but it would be > easy > > to imagine. E.g. I might have an editor display: > > > > url = f'{URL_BASE}&arg1={row["column_*(..93 chars..)*rg17=123456' > > > > Does anyone know of editors that do that sort of thing? Obviously, > > you'd need some way to fold/unfold the hidden text. But for many > > purposes, the first and last few characters probably convey the > > purpose of the line. > > You may not like my answer: Emacs does several kinds of hiding text. > They're not exactly what you ask for, of course, but the tools are > definitely there. > > The only automatic hiding features I use are truncate-lines mode, > which as you might guess hides the tail of the line by default, but > also scrolls only that line if point moves into the hidden tail (as > many browsers do in their address bars), and outline mode, which has a > couple of ways to tweak display (hide non-heading text, hide > subheadings, do either locally or globally). I don't know who > maintains python-mode, but they might be interested in your suggestion > if you're interested in an Emacs feature. > > Whoever maintains python-mode is exceptionally open to wacky (ie, > contra GNUish orthodoxy) ideas, I must say. It's the only mode I use > where RET is bound to newline-and-indent instead of newline, for > example. > > > -- > Associate Professor Division of Policy and Planning Science > http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information > Email: turnbull at sk.tsukuba.ac.jp University of Tsukuba > Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Vinicius Mesel CEO e Fundador do PyJobs http://www.pyjobs.com.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhodri at kynesim.co.uk Wed Feb 27 08:37:38 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Wed, 27 Feb 2019 13:37:38 +0000 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: On 26/02/2019 02:01, Christopher Barker wrote: > We could reword: > > """ > Some teams strongly prefer a longer line length. For code maintained > exclusively or primarily by a team that can reach agreement on this issue, > it is okay to increase the nominal line length from 80 to 100 characters > (effectively increasing the maximum length to 99 characters), provided that > comments and docstrings are still wrapped at 72 characters. > """ > > To be a bit less harsh -- that is, change the clause: > > "For code maintained exclusively or primarily by a team that can reach > agreement on this issue, it is okay ..." > > To maybe just > > "For code maintained by a team that can reach agreement on this issue, it > is okay ..." I would prefer not. The wording as given emphasizes that the team isn't expecting outsiders to work on their code. I think that's quite important, especially when you consider that PEP8 only really has force for the standard library. -- Rhodri James *-* Kynesim Ltd From jcrmatos at gmail.com Wed Feb 27 11:25:02 2019 From: jcrmatos at gmail.com (=?UTF-8?Q?Jo=c3=a3o_Matos?=) Date: Wed, 27 Feb 2019 16:25:02 +0000 Subject: [Python-ideas] Dict joining using + and += Message-ID: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3988 bytes Desc: S/MIME Cryptographic Signature URL: From rhodri at kynesim.co.uk Wed Feb 27 11:44:11 2019 From: rhodri at kynesim.co.uk (Rhodri James) Date: Wed, 27 Feb 2019 16:44:11 +0000 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: On 27/02/2019 16:25, Jo?o Matos wrote: > Hello, > > I would like to propose that instead of using this (applies to Py3.5 and upwards) > dict_a = {**dict_a, **dict_b} > > we could use > dict_a = dict_a + dict_b > > or even better > dict_a += dict_b While I don't object to the idea of concatenating dictionaries, I feel obliged to point out that this last is currently spelled dict_a.update(dict_b) -- Rhodri James *-* Kynesim Ltd From guido at python.org Wed Feb 27 12:05:20 2019 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Feb 2019 09:05:20 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: On Wed, Feb 27, 2019 at 8:50 AM Rhodri James wrote: > On 27/02/2019 16:25, Jo?o Matos wrote: > > I would like to propose that instead of using this (applies to Py3.5 and > upwards) > > dict_a = {**dict_a, **dict_b} > > > > we could use > > dict_a = dict_a + dict_b > > > > or even better > > dict_a += dict_b > > While I don't object to the idea of concatenating dictionaries, I feel > obliged to point out that this last is currently spelled > dict_a.update(dict_b) > This is likely to be controversial. But I like the idea. After all, we have `list.extend(x)` ~~ `list += x`. The key conundrum that needs to be solved is what to do for `d1 + d2` when there are overlapping keys. I propose to make d2 win in this case, which is what happens in `d1.update(d2)` anyways. If you want it the other way, simply write `d2 + d1`. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmcastil at gmail.com Wed Feb 27 12:34:43 2019 From: gmcastil at gmail.com (George Castillo) Date: Wed, 27 Feb 2019 10:34:43 -0700 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: > > The key conundrum that needs to be solved is what to do for `d1 + d2` when > there are overlapping keys. I propose to make d2 win in this case, which is > what happens in `d1.update(d2)` anyways. If you want it the other way, > simply write `d2 + d1`. This would mean that addition, at least in this particular instance, is not a commutative operation. Are there other places in Python where this is the case? ~ George On Wed, Feb 27, 2019 at 10:06 AM Guido van Rossum wrote: > On Wed, Feb 27, 2019 at 8:50 AM Rhodri James wrote: > >> On 27/02/2019 16:25, Jo?o Matos wrote: >> > I would like to propose that instead of using this (applies to Py3.5 >> and upwards) >> > dict_a = {**dict_a, **dict_b} >> > >> > we could use >> > dict_a = dict_a + dict_b >> > >> > or even better >> > dict_a += dict_b >> >> While I don't object to the idea of concatenating dictionaries, I feel >> obliged to point out that this last is currently spelled >> dict_a.update(dict_b) >> > > This is likely to be controversial. But I like the idea. After all, we > have `list.extend(x)` ~~ `list += x`. The key conundrum that needs to be > solved is what to do for `d1 + d2` when there are overlapping keys. I > propose to make d2 win in this case, which is what happens in > `d1.update(d2)` anyways. If you want it the other way, simply write `d2 + > d1`. > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phd at phdru.name Wed Feb 27 12:17:48 2019 From: phd at phdru.name (Oleg Broytman) Date: Wed, 27 Feb 2019 18:17:48 +0100 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: <20190227171748.rdolkdz7mmva4ped@phdru.name> On Wed, Feb 27, 2019 at 09:05:20AM -0800, Guido van Rossum wrote: > On Wed, Feb 27, 2019 at 8:50 AM Rhodri James wrote: > > > On 27/02/2019 16:25, Jo??o Matos wrote: > > > I would like to propose that instead of using this (applies to Py3.5 and > > upwards) > > > dict_a = {**dict_a, **dict_b} > > > > > > we could use > > > dict_a = dict_a + dict_b > > > > > > or even better > > > dict_a += dict_b > > > > While I don't object to the idea of concatenating dictionaries, I feel > > obliged to point out that this last is currently spelled > > dict_a.update(dict_b) > > > > This is likely to be controversial. But I like the idea. After all, we have > `list.extend(x)` ~~ `list += x`. The key conundrum that needs to be solved > is what to do for `d1 + d2` when there are overlapping keys. I propose to > make d2 win in this case, which is what happens in `d1.update(d2)` anyways. > If you want it the other way, simply write `d2 + d1`. That is, ``d1 + d2`` is:: d = d1.copy() d.update(d2) return d > -- > --Guido van Rossum (python.org/~guido) Oleg. -- Oleg Broytman https://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From erik.m.bray at gmail.com Wed Feb 27 12:37:01 2019 From: erik.m.bray at gmail.com (E. Madison Bray) Date: Wed, 27 Feb 2019 18:37:01 +0100 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: On Wed, Feb 27, 2019 at 6:35 PM George Castillo wrote: >> >> The key conundrum that needs to be solved is what to do for `d1 + d2` when there are overlapping keys. I propose to make d2 win in this case, which is what happens in `d1.update(d2)` anyways. If you want it the other way, simply write `d2 + d1`. > > > This would mean that addition, at least in this particular instance, is not a commutative operation. Are there other places in Python where this is the case? Sure: >>> a = "A" >>> b = "B" >>> a + b == b + a False > On Wed, Feb 27, 2019 at 10:06 AM Guido van Rossum wrote: >> >> On Wed, Feb 27, 2019 at 8:50 AM Rhodri James wrote: >>> >>> On 27/02/2019 16:25, Jo?o Matos wrote: >>> > I would like to propose that instead of using this (applies to Py3.5 and upwards) >>> > dict_a = {**dict_a, **dict_b} >>> > >>> > we could use >>> > dict_a = dict_a + dict_b >>> > >>> > or even better >>> > dict_a += dict_b >>> >>> While I don't object to the idea of concatenating dictionaries, I feel >>> obliged to point out that this last is currently spelled >>> dict_a.update(dict_b) >> >> >> This is likely to be controversial. But I like the idea. After all, we have `list.extend(x)` ~~ `list += x`. The key conundrum that needs to be solved is what to do for `d1 + d2` when there are overlapping keys. I propose to make d2 win in this case, which is what happens in `d1.update(d2)` anyways. If you want it the other way, simply write `d2 + d1`. >> >> -- >> --Guido van Rossum (python.org/~guido) >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From guido at python.org Wed Feb 27 12:37:00 2019 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Feb 2019 09:37:00 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: On Wed, Feb 27, 2019 at 9:34 AM George Castillo wrote: > The key conundrum that needs to be solved is what to do for `d1 + d2` when >> there are overlapping keys. I propose to make d2 win in this case, which is >> what happens in `d1.update(d2)` anyways. If you want it the other way, >> simply write `d2 + d1`. > > > This would mean that addition, at least in this particular instance, is > not a commutative operation. Are there other places in Python where this > is the case? > Yes there are. 'a' + 'b' is not the same as 'b' + 'a'. For non-numbers we only require + to be associative, i.e. a + b + c == (a + b) + c == a + (b + c). That is satisfied for this proposal. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Wed Feb 27 13:14:38 2019 From: python at mrabarnett.plus.com (MRAB) Date: Wed, 27 Feb 2019 18:14:38 +0000 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: <8899b5c1-0b56-e04b-6437-89fa71e6fa25@mrabarnett.plus.com> On 2019-02-27 17:37, Guido van Rossum wrote: > On Wed, Feb 27, 2019 at 9:34 AM George Castillo > wrote: > > The key conundrum that needs to be solved is what to do for `d1 > + d2` when there are overlapping keys. I propose to make d2 win > in this case, which is what happens in `d1.update(d2)` anyways. > If you want it the other way, simply write `d2 + d1`. > > > This would mean that addition, at least in this particular instance, > is not a commutative operation.? Are there other places in Python > where this is the case? > > > Yes there are. 'a' + 'b' is not the same as 'b' + 'a'. > > For non-numbers we only require + to be associative, i.e. a + b + c == > (a + b) + c == a + (b + c). > > That is satisfied for this proposal. > Are there any advantages of using '+' over '|'? From boxed at killingar.net Wed Feb 27 13:22:10 2019 From: boxed at killingar.net (=?utf-8?Q?Anders_Hovm=C3=B6ller?=) Date: Wed, 27 Feb 2019 19:22:10 +0100 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> I dislike the asymmetry with sets: > {1} | {2} {1, 2} To me it makes sense that if + works for dict then it should for set too. / Anders > On 27 Feb 2019, at 17:25, Jo?o Matos wrote: > > Hello, > > I would like to propose that instead of using this (applies to Py3.5 and upwards) > dict_a = {**dict_a, **dict_b} > > we could use > dict_a = dict_a + dict_b > > or even better > dict_a += dict_b > > > Best regards, > > Jo?o Matos > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From mike at selik.org Wed Feb 27 13:41:04 2019 From: mike at selik.org (Michael Selik) Date: Wed, 27 Feb 2019 10:41:04 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: On Wed, Feb 27, 2019 at 10:22 AM Anders Hovm?ller wrote: > I dislike the asymmetry with sets: > > > {1} | {2} > {1, 2} > > To me it makes sense that if + works for dict then it should for set too. > > / Anders > > > On 27 Feb 2019, at 17:25, Jo?o Matos wrote: > > > > Hello, > > > > I would like to propose that instead of using this (applies to Py3.5 and > upwards) > > dict_a = {**dict_a, **dict_b} > > > > we could use > > dict_a = dict_a + dict_b > The dict subclass collections.Counter overrides the update method for adding values instead of overwriting values. https://docs.python.org/3/library/collections.html#collections.Counter.update Counter also uses +/__add__ for a similar behavior. >>> c = Counter(a=3, b=1) >>> d = Counter(a=1, b=2) >>> c + d # add two counters together: c[x] + d[x] Counter({'a': 4, 'b': 3}) At first I worried that changing base dict would cause confusion for the subclass, but Counter seems to share the idea that update and + are synonyms. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Wed Feb 27 13:48:21 2019 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Feb 2019 10:48:21 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: On Wed, Feb 27, 2019 at 10:42 AM Michael Selik wrote: > > > On Wed, Feb 27, 2019 at 10:22 AM Anders Hovm?ller > wrote: > >> I dislike the asymmetry with sets: >> >> > {1} | {2} >> {1, 2} >> >> To me it makes sense that if + works for dict then it should for set too. >> >> / Anders >> >> > On 27 Feb 2019, at 17:25, Jo?o Matos wrote: >> > >> > Hello, >> > >> > I would like to propose that instead of using this (applies to Py3.5 >> and upwards) >> > dict_a = {**dict_a, **dict_b} >> > >> > we could use >> > dict_a = dict_a + dict_b >> > > > The dict subclass collections.Counter overrides the update method for > adding values instead of overwriting values. > > > https://docs.python.org/3/library/collections.html#collections.Counter.update > > Counter also uses +/__add__ for a similar behavior. > > >>> c = Counter(a=3, b=1) > >>> d = Counter(a=1, b=2) > >>> c + d # add two counters together: c[x] + d[x] > Counter({'a': 4, 'b': 3}) > > At first I worried that changing base dict would cause confusion for the > subclass, but Counter seems to share the idea that update and + are > synonyms. > Great, this sounds like a good argument for + over |. The other argument is that | for sets *is* symmetrical, while + is used for other collections where it's not symmetrical. So it sounds like + is a winner here. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcrmatos at gmail.com Wed Feb 27 14:05:18 2019 From: jcrmatos at gmail.com (=?UTF-8?Q?Jo=c3=a3o_Matos?=) Date: Wed, 27 Feb 2019 19:05:18 +0000 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: <538a982e-3a46-2610-1f92-74252d2019f6@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3988 bytes Desc: S/MIME Cryptographic Signature URL: From guido at python.org Wed Feb 27 14:08:50 2019 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Feb 2019 11:08:50 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <538a982e-3a46-2610-1f92-74252d2019f6@gmail.com> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> <538a982e-3a46-2610-1f92-74252d2019f6@gmail.com> Message-ID: On Wed, Feb 27, 2019 at 11:06 AM Jo?o Matos wrote: > Great. > Because I don't program in any other language except Python, I can't make > the PR (with the C code). > Maybe someone who program in C can help? > First we need a PEP, and for a PEP you need a core dev interested in sponsoring the PEP. And I'm not it. Is there a core dev who is interested in sponsoring or co-authoring this PEP? -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mertz at gnosis.cx Wed Feb 27 15:11:21 2019 From: mertz at gnosis.cx (David Mertz) Date: Wed, 27 Feb 2019 15:11:21 -0500 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: "foo" + "bar" != "bar" + "foo" On Wed, Feb 27, 2019, 12:35 PM George Castillo wrote: > The key conundrum that needs to be solved is what to do for `d1 + d2` when >> there are overlapping keys. I propose to make d2 win in this case, which is >> what happens in `d1.update(d2)` anyways. If you want it the other way, >> simply write `d2 + d1`. > > > This would mean that addition, at least in this particular instance, is > not a commutative operation. Are there other places in Python where this > is the case? > > ~ George > > > On Wed, Feb 27, 2019 at 10:06 AM Guido van Rossum > wrote: > >> On Wed, Feb 27, 2019 at 8:50 AM Rhodri James >> wrote: >> >>> On 27/02/2019 16:25, Jo?o Matos wrote: >>> > I would like to propose that instead of using this (applies to Py3.5 >>> and upwards) >>> > dict_a = {**dict_a, **dict_b} >>> > >>> > we could use >>> > dict_a = dict_a + dict_b >>> > >>> > or even better >>> > dict_a += dict_b >>> >>> While I don't object to the idea of concatenating dictionaries, I feel >>> obliged to point out that this last is currently spelled >>> dict_a.update(dict_b) >>> >> >> This is likely to be controversial. But I like the idea. After all, we >> have `list.extend(x)` ~~ `list += x`. The key conundrum that needs to be >> solved is what to do for `d1 + d2` when there are overlapping keys. I >> propose to make d2 win in this case, which is what happens in >> `d1.update(d2)` anyways. If you want it the other way, simply write `d2 + >> d1`. >> >> -- >> --Guido van Rossum (python.org/~guido) >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandtbucher at gmail.com Wed Feb 27 15:18:06 2019 From: brandtbucher at gmail.com (Brandt Bucher) Date: Wed, 27 Feb 2019 12:18:06 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <538a982e-3a46-2610-1f92-74252d2019f6@gmail.com> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> <538a982e-3a46-2610-1f92-74252d2019f6@gmail.com> Message-ID: I?d like to try my hand at implementing this, if nobody else is interested. I should be able to have something up today. Brandt > On Feb 27, 2019, at 11:05, Jo?o Matos wrote: > > Hello, > > Great. > Because I don't program in any other language except Python, I can't make the PR (with the C code). > Maybe someone who program in C can help? > > Best regards, > > Jo?o Matos >> On 27-02-2019 18:48, Guido van Rossum wrote: >> >>> On Wed, Feb 27, 2019 at 10:42 AM Michael Selik wrote: >>> >>> >>>> On Wed, Feb 27, 2019 at 10:22 AM Anders Hovm?ller wrote: >>>> I dislike the asymmetry with sets: >>>> >>>> > {1} | {2} >>>> {1, 2} >>>> >>>> To me it makes sense that if + works for dict then it should for set too. >>>> >>>> / Anders >>>> >>>> > On 27 Feb 2019, at 17:25, Jo?o Matos wrote: >>>> > >>>> > Hello, >>>> > >>>> > I would like to propose that instead of using this (applies to Py3.5 and upwards) >>>> > dict_a = {**dict_a, **dict_b} >>>> > >>>> > we could use >>>> > dict_a = dict_a + dict_b >>> >>> >>> The dict subclass collections.Counter overrides the update method for adding values instead of overwriting values. >>> >>> https://docs.python.org/3/library/collections.html#collections.Counter.update >>> >>> Counter also uses +/__add__ for a similar behavior. >>> >>> >>> c = Counter(a=3, b=1) >>> >>> d = Counter(a=1, b=2) >>> >>> c + d # add two counters together: c[x] + d[x] >>> Counter({'a': 4, 'b': 3}) >>> >>> At first I worried that changing base dict would cause confusion for the subclass, but Counter seems to share the idea that update and + are synonyms. >> >> Great, this sounds like a good argument for + over |. The other argument is that | for sets *is* symmetrical, while + is used for other collections where it's not symmetrical. So it sounds like + is a winner here. >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Wed Feb 27 15:19:49 2019 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 27 Feb 2019 21:19:49 +0100 Subject: [Python-ideas] Dict joining using + and += References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: <20190227211949.49cbfc76@fsol> On Wed, 27 Feb 2019 10:48:21 -0800 Guido van Rossum wrote: > > Great, this sounds like a good argument for + over |. The other argument is > that | for sets *is* symmetrical, [...] As much as it can be: >>> {-0.0} | {0.0} {-0.0} >>> {0.0} | {-0.0} {0.0} ;-) Antoine. From chris.barker at noaa.gov Wed Feb 27 18:02:00 2019 From: chris.barker at noaa.gov (Chris Barker) Date: Wed, 27 Feb 2019 15:02:00 -0800 Subject: [Python-ideas] PEP 8 update on line length In-Reply-To: References: Message-ID: On Wed, Feb 27, 2019 at 5:53 AM Rhodri James wrote: > > To be a bit less harsh -- that is, change the clause: > > > > "For code maintained exclusively or primarily by a team that can reach > > agreement on this issue, it is okay ..." > > > > To maybe just > > > > "For code maintained by a team that can reach agreement on this issue, > it > > is okay ..." > > I would prefer not. The wording as given emphasizes that the team isn't > expecting outsiders to work on their code. I think that's quite > important, especially when you consider that PEP8 only really has force > for the standard library. > Huh? in the case of the stdlib, the "team" is the python core devs -- they could decide to increase the line length if they want (though I imagine if they did, they's probably change the PEP :- ) Anyway, not a biggie -- just might get folks to chill out a bit and stop pushing to change the PEP ... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at pearwood.info Wed Feb 27 18:46:39 2019 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 28 Feb 2019 10:46:39 +1100 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: <20190227234639.GC4465@ando.pearwood.info> On Wed, Feb 27, 2019 at 10:34:43AM -0700, George Castillo wrote: > > > > The key conundrum that needs to be solved is what to do for `d1 + d2` when > > there are overlapping keys. I propose to make d2 win in this case, which is > > what happens in `d1.update(d2)` anyways. If you want it the other way, > > simply write `d2 + d1`. > > > This would mean that addition, at least in this particular instance, is not > a commutative operation. Are there other places in Python where this is > the case? Strings, bytes, lists, tuples. In this case, I wouldn't call it dict addition, I would call it a union operator. That suggests that maybe we match sets and use | for union. That also suggests d1 & d2 for the intersection between two dicts, but which value should win? More useful than intersection is, I think, dict subtraction: d1 - d2 being a new dict with the keys/values from d1 which aren't in d2. -- Steven From guido at python.org Wed Feb 27 19:07:29 2019 From: guido at python.org (Guido van Rossum) Date: Wed, 27 Feb 2019 16:07:29 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <20190227234639.GC4465@ando.pearwood.info> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <20190227234639.GC4465@ando.pearwood.info> Message-ID: OK, you're it. Please write a PEP for this. On Wed, Feb 27, 2019 at 3:53 PM Steven D'Aprano wrote: > On Wed, Feb 27, 2019 at 10:34:43AM -0700, George Castillo wrote: > > > > > > The key conundrum that needs to be solved is what to do for `d1 + d2` > when > > > there are overlapping keys. I propose to make d2 win in this case, > which is > > > what happens in `d1.update(d2)` anyways. If you want it the other way, > > > simply write `d2 + d1`. > > > > > > This would mean that addition, at least in this particular instance, is > not > > a commutative operation. Are there other places in Python where this is > > the case? > > Strings, bytes, lists, tuples. > > In this case, I wouldn't call it dict addition, I would call it a union > operator. That suggests that maybe we match sets and use | for union. > > That also suggests d1 & d2 for the intersection between two dicts, but > which value should win? > > More useful than intersection is, I think, dict subtraction: d1 - d2 > being a new dict with the keys/values from d1 which aren't in d2. > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandtbucher at gmail.com Wed Feb 27 23:21:44 2019 From: brandtbucher at gmail.com (Brandt Bucher) Date: Wed, 27 Feb 2019 20:21:44 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <20190227234639.GC4465@ando.pearwood.info> Message-ID: <30C5B47A-4D71-4E12-A2F6-DB17C427B1CD@gmail.com> Here is a working implementation of dictionary addition, for consideration with the PEP: https://bugs.python.org/issue36144 Brandt > On Feb 27, 2019, at 16:07, Guido van Rossum wrote: > > OK, you're it. Please write a PEP for this. > >> On Wed, Feb 27, 2019 at 3:53 PM Steven D'Aprano wrote: >> On Wed, Feb 27, 2019 at 10:34:43AM -0700, George Castillo wrote: >> > > >> > > The key conundrum that needs to be solved is what to do for `d1 + d2` when >> > > there are overlapping keys. I propose to make d2 win in this case, which is >> > > what happens in `d1.update(d2)` anyways. If you want it the other way, >> > > simply write `d2 + d1`. >> > >> > >> > This would mean that addition, at least in this particular instance, is not >> > a commutative operation. Are there other places in Python where this is >> > the case? >> >> Strings, bytes, lists, tuples. >> >> In this case, I wouldn't call it dict addition, I would call it a union >> operator. That suggests that maybe we match sets and use | for union. >> >> That also suggests d1 & d2 for the intersection between two dicts, but >> which value should win? >> >> More useful than intersection is, I think, dict subtraction: d1 - d2 >> being a new dict with the keys/values from d1 which aren't in d2. >> >> >> >> -- >> Steven >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Thu Feb 28 02:16:55 2019 From: storchaka at gmail.com (Serhiy Storchaka) Date: Thu, 28 Feb 2019 09:16:55 +0200 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: 27.02.19 20:48, Guido van Rossum ????: > > On Wed, Feb 27, 2019 at 10:42 AM Michael Selik > > wrote > The dict subclass collections.Counter overrides the update method > for adding values instead of overwriting values. > > https://docs.python.org/3/library/collections.html#collections.Counter.update > > Counter also uses?+/__add__ for a similar behavior. > > ? ? >>> c = Counter(a=3, b=1) > ? ? >>> d = Counter(a=1, b=2) > ? ? >>> c + d # add two counters together:? c[x] + d[x] > ? ? Counter({'a': 4, 'b': 3}) > > At first I worried that changing base dict would cause confusion for > the subclass, but Counter seems to share the idea that update and?+ > are synonyms. > > > Great, this sounds like a good argument for + over |. The other argument > is that | for sets *is* symmetrical, while + is used for other > collections where it's not symmetrical. So it sounds like + is a winner > here. Counter uses + for a *different* behavior! >>> Counter(a=2) + Counter(a=3) Counter({'a': 5}) I do not understand why we discuss a new syntax for dict merging if we already have a syntax for dict merging: {**d1, **d2} (which works with *all* mappings). Is not this contradicts the Zen? From eric at trueblade.com Wed Feb 27 14:43:24 2019 From: eric at trueblade.com (Eric V. Smith) Date: Wed, 27 Feb 2019 14:43:24 -0500 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> <538a982e-3a46-2610-1f92-74252d2019f6@gmail.com> Message-ID: <1e5a4494-f16b-ca10-ab16-607dceb8f80d@trueblade.com> On 2/27/2019 2:08 PM, Guido van Rossum wrote: > On Wed, Feb 27, 2019 at 11:06 AM Jo?o Matos > wrote: > > Great. > Because I don't program in any other language except Python, I can't > make the PR (with the C code). > Maybe someone who program in C can help? > > > First we need a PEP, and for a PEP you need a core dev interested in > sponsoring the PEP. And I'm not it. Is there a core dev who is > interested in sponsoring or co-authoring this PEP? I'd help out. Eric From jamtlu at gmail.com Thu Feb 28 07:40:25 2019 From: jamtlu at gmail.com (James Lu) Date: Thu, 28 Feb 2019 07:40:25 -0500 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: <9B095C8A-A040-4DA8-A41B-30C250E01524@gmail.com> I agree with Storchaka here. The advantage of existing dict merge syntax is that it will cause an error if the object is not a dict or dict-like object, thus preventing people from doing bad things. > On Feb 28, 2019, at 2:16 AM, Serhiy Storchaka wrote: > > 27.02.19 20:48, Guido van Rossum ????: >> On Wed, Feb 27, 2019 at 10:42 AM Michael Selik > wrote > The dict subclass collections.Counter overrides the update method >> for adding values instead of overwriting values. >> https://docs.python.org/3/library/collections.html#collections.Counter.update >> Counter also uses +/__add__ for a similar behavior. >> >>> c = Counter(a=3, b=1) >> >>> d = Counter(a=1, b=2) >> >>> c + d # add two counters together: c[x] + d[x] >> Counter({'a': 4, 'b': 3}) >> At first I worried that changing base dict would cause confusion for >> the subclass, but Counter seems to share the idea that update and + >> are synonyms. >> Great, this sounds like a good argument for + over |. The other argument is that | for sets *is* symmetrical, while + is used for other collections where it's not symmetrical. So it sounds like + is a winner here. > > Counter uses + for a *different* behavior! > > >>> Counter(a=2) + Counter(a=3) > Counter({'a': 5}) > > I do not understand why we discuss a new syntax for dict merging if we already have a syntax for dict merging: {**d1, **d2} (which works with *all* mappings). Is not this contradicts the Zen? > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ From tir.karthi at gmail.com Thu Feb 28 12:42:31 2019 From: tir.karthi at gmail.com (Karthikeyan) Date: Thu, 28 Feb 2019 23:12:31 +0530 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> Message-ID: Just to add to the discussion this was brought up previously as part of PEP 448 unpacking generalizations that also added {**x, **y} to merge two dicts in Python 3.5. Previous python ideas thread : https://mail.python.org/pipermail/python-ideas/2015-February/031748.html LWN summary : https://lwn.net/Articles/635397/ The previous thread is worth reading as some of the points still stand even with {**x, **y} added. On Wed, Feb 27, 2019 at 9:59 PM Jo?o Matos wrote: > Hello, > > I would like to propose that instead of using this (applies to Py3.5 and > upwards) > dict_a = {**dict_a, **dict_b} > > we could use > dict_a = dict_a + dict_b > > or even better > dict_a += dict_b > > > Best regards, > > Jo?o Matos > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Regards, Karthikeyan S -------------- next part -------------- An HTML attachment was scrubbed... URL: From t_glaessle at gmx.de Thu Feb 28 15:23:13 2019 From: t_glaessle at gmx.de (=?UTF-8?B?VGhvbWFzIEdsw6TDn2xl?=) Date: Thu, 28 Feb 2019 21:23:13 +0100 Subject: [Python-ideas] Allow async defs for __await__ Message-ID: <2ace3b30-7e79-750f-9cac-bc01846329d6@gmx.de> Hi, I suggest to allow defining awaitable classes in terms of `async def`-s: ??? class FeynmanAlgorithm: ??????? async def __await__(self): ??????????? await self.write_down_the_problem() ??? ??? ??? await self.think_real_hard() ??? ??? ??? await self.write_down_the_solution() IMO, this would be the "one obvious way" for anyone who's using it for anything other than defining low-level primitives. It is also easier to teach and and more consistent with how you can define iterables - where `__iter__` is explicitly allowed to be defined in terms of generator function (which I would consider the equivalent to the async defs of awaitables). The implementation could be as easy as calling `__await__` as long as the returned object is not an iterator instead of going straight to TypeError. Currently `__await__` must return an iterator, and one has to define a separate function or method (or use a decorator) to do the same, e.g.: ??? class FeynmanAlgorithm: ??? ??? def __await__(self): ??? ??? ??? return self.perform().__await__() ??? ??? async def perform(self): ??? ??? ??? [...] IMO, this is far from obvious and has been subject to a few subtle differences between python versions. For example: ??? import asyncio ??? class Waiter: ??? ??? def __await__(self): ??? ??? ??? return asyncio.sleep(1).__await__() ??? asyncio.get_event_loop().run_until_complete( ??? ??? asyncio.ensure_future(Waiter())) works fine on python 3.7 but fails on python 3.5 with "AttributeError: 'generator' object has no attribute '__await__'" because some awaitables are implemented using generator type coroutines. Adding to potential confusion, `async def __await__` seems to be work in certain situations: ??? import asyncio ??? class Waiter: ??? ??? async def __await__(self): ??????? ??? await asyncio.sleep(1) ??? # this works on py3.7: ??? asyncio.get_event_loop().run_until_complete( ??? ??? asyncio.ensure_future(Waiter())) but, awaiting them in a coroutine context causes an error: ??? async def foo(): ??? ??? await Waiter() ??? # "TypeError: __await__() returned a coroutine": ??? asyncio.get_event_loop().run_until_complete( ??? ??? asyncio.ensure_future(foo())) In earlier python versions (at least up to 3.5) the situation is somewhat reversed. The `yield from` analogue of the above used to work in coroutine context: ??? import asyncio ??? class Waiter: ??? ??? def __iter__(self): ??????? ??? yield from asyncio.sleep(1) ??? @asyncio.coroutine ??? def foo(): ??? ??? yield from Waiter() ??? # works on py3.5: ??? asyncio.get_event_loop().run_until_complete( ??? ??? asyncio.ensure_future(foo())) While the following doesn't: ??? # "TypeError: An asyncio.Future, a coroutine or an awaitable is required": ??? asyncio.get_event_loop().run_until_complete( ??? ??? asyncio.ensure_future(Waiter())) What do you think? Kind regards, Thomas See also: https://stackoverflow.com/questions/33409888/how-can-i-await-inside-future-like-objects-await -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: OpenPGP digital signature URL: From greg.ewing at canterbury.ac.nz Thu Feb 28 16:19:42 2019 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 01 Mar 2019 10:19:42 +1300 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: <5C78506E.6040600@canterbury.ac.nz> Serhiy Storchaka wrote: > I do not understand why we discuss a new syntax for dict merging if we > already have a syntax for dict merging: {**d1, **d2} (which works with > *all* mappings). But that always returns a dict. A '+' operator could be implemented by other mapping types to return a mapping of the same type. -- Greg From guido at python.org Thu Feb 28 23:21:45 2019 From: guido at python.org (Guido van Rossum) Date: Thu, 28 Feb 2019 20:21:45 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: On Wed, Feb 27, 2019 at 11:18 PM Serhiy Storchaka wrote: > 27.02.19 20:48, Guido van Rossum ????: > > > > On Wed, Feb 27, 2019 at 10:42 AM Michael Selik > > > > wrote > The dict subclass > collections.Counter overrides the update method > > for adding values instead of overwriting values. > > > > > https://docs.python.org/3/library/collections.html#collections.Counter.update > > > > Counter also uses +/__add__ for a similar behavior. > > > > >>> c = Counter(a=3, b=1) > > >>> d = Counter(a=1, b=2) > > >>> c + d # add two counters together: c[x] + d[x] > > Counter({'a': 4, 'b': 3}) > > > > At first I worried that changing base dict would cause confusion for > > the subclass, but Counter seems to share the idea that update and + > > are synonyms. > > > > > > Great, this sounds like a good argument for + over |. The other argument > > is that | for sets *is* symmetrical, while + is used for other > > collections where it's not symmetrical. So it sounds like + is a winner > > here. > > Counter uses + for a *different* behavior! > > >>> Counter(a=2) + Counter(a=3) > Counter({'a': 5}) > Well, you can see this as a special case. The proposed + operator on Mappings returns a new Mapping whose keys are the union of the keys of the two arguments; the value is the single value for a key that occurs in only one of the arguments, and *somehow* combined for a key that's in both. The way of combining keys is up to the type of Mapping. For dict, the second value wins (not so different as {'a': 1, 'a': 2}, which becomes {'a': 2}). But for other Mappings, the combination can be done differently -- and Counter chooses to add the two values. > I do not understand why we discuss a new syntax for dict merging if we > already have a syntax for dict merging: {**d1, **d2} (which works with > *all* mappings). Is not this contradicts the Zen? > But (as someone else pointed out) {**d1, **d2} always returns a dict, not the type of d1 and d2. Also, I'm sorry for PEP 448, but even if you know about **d in simpler contexts, if you were to ask a typical Python user how to combine two dicts into a new one, I doubt many people would think of {**d1, **d2}. I know I myself had forgotten about it when this thread started! If you were to ask a newbie who has learned a few things (e.g. sequence concatenation) they would much more likely guess d1+d2. The argument for + over | has been mentioned elsewhere already. @Eric Smith > I'd help out. Please do! I tried to volunteer Stephen d'Aprano but I think he isn't interested in pushing through a controversial PEP. The PEP should probably also propose d1-d2. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tir.karthi at gmail.com Thu Feb 28 23:58:08 2019 From: tir.karthi at gmail.com (Karthikeyan) Date: Fri, 1 Mar 2019 10:28:08 +0530 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: The PEP should probably also propose d1-d2. > What would be the output of this? Does this return a new dictionary where keys in d2 are removed in d1 like sets? >>> d = dict((i, i) for i in range(5)) >>> e = dict((i, i) for i in range(4, 10)) >>> d {0: 0, 1: 1, 2: 2, 3: 3, 4: 4} >>> e {4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} >>> d.items() - e.items() {(0, 0), (1, 1), (3, 3), (2, 2)} >>> dict(d.items() - e.items()) {0: 0, 1: 1, 3: 3, 2: 2} -- Regards, Karthikeyan S -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasan.diwan at gmail.com Thu Feb 28 23:59:30 2019 From: hasan.diwan at gmail.com (Hasan Diwan) Date: Thu, 28 Feb 2019 20:59:30 -0800 Subject: [Python-ideas] Dict joining using + and += In-Reply-To: References: <0433166f-4f88-93d6-327b-ed1708c17fa7@gmail.com> <378B4AB0-A949-462F-ADCE-10D40E3969CC@killingar.net> Message-ID: Do we really need a "+" and a "-" operation on dictionaries? [dictinstance.update({k:v}) for k,v in dictinstance.items()] does handle merges already. And I'm assuming that "-" should return the difference -- set(d1.keys()) - set(d2.keys()), right? -- H -- OpenPGP: https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1 If you wish to request my time, please do so using *bit.ly/hd1AppointmentRequest *. Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest *. Sent from my mobile device Envoye de mon portable -------------- next part -------------- An HTML attachment was scrubbed... URL: