From abarnert at yahoo.com Sun Dec 1 00:42:31 2013 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 30 Nov 2013 15:42:31 -0800 Subject: [Python-ideas] string codes & substring equality In-Reply-To: <5298390B.30506@canterbury.ac.nz> References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz> Message-ID: On Nov 28, 2013, at 22:49, Greg Ewing wrote: > spir wrote: >> (But then, possibly, some would wonder why this new ord(s,i) is not a string method ;-) > > For the same reason that the existing ord() function isn't > a string method, whatever that is! http://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list The short version is: historical reasons, and no reason to change it compelling enough to be worth the costs in backward compat, bikeshedding, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Sun Dec 1 00:48:57 2013 From: guido at python.org (Guido van Rossum) Date: Sat, 30 Nov 2013 15:48:57 -0800 Subject: [Python-ideas] string codes & substring equality In-Reply-To: References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz> Message-ID: On Sat, Nov 30, 2013 at 3:42 PM, Andrew Barnert wrote: > On Nov 28, 2013, at 22:49, Greg Ewing wrote: > > spir wrote: > > (But then, possibly, some would wonder why this new ord(s,i) is not a > string method ;-) > > > For the same reason that the existing ord() function isn't > a string method, whatever that is! > > > > http://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list > > The short version is: historical reasons, and no reason to change it > compelling enough to be worth the costs in backward compat, bikeshedding, > etc. > That FAQ entry does not do the real motivation justice. While OO "purists" may argue about it, to me it's obvious that in quite a few cases the function spelling is more readable than the method spelling. I found it more readable 23 years ago, and I still find it more readable today. So it's not historical reasons to me, even if not everybody agrees (obviously :-). -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Sun Dec 1 02:23:17 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 30 Nov 2013 20:23:17 -0500 Subject: [Python-ideas] string codes & substring equality In-Reply-To: References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz>

Message-ID: On 11/30/2013 6:48 PM, Guido van Rossum wrote: > > On Sat, Nov 30, 2013 at 3:42 PM, Andrew Barnert > > wrote: > > On Nov 28, 2013, at 22:49, Greg Ewing > > wrote: > >> spir wrote: >>> (But then, possibly, some would wonder why this new ord(s,i) is >>> not a string method ;-) ord and chr are inverse functions. Would you have chr be an int method? (Even if yes, history comes into play here as ints did not have methods until 2.2(?, or close to that). >> For the same reason that the existing ord() function isn't >> a string method, whatever that is! > > http://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list > > The short version is: historical reasons, and no reason to change it > compelling enough to be worth the costs in backward compat, > bikeshedding, etc. > > > That FAQ entry does not do the real motivation justice. While OO > "purists" may argue about it, to me it's obvious that in quite a few > cases the function spelling is more readable than the method spelling. I > found it more readable 23 years ago, and I still find it more readable > today. So it's not historical reasons to me, even if not everybody > agrees (obviously :-). Sometimes functions are more functional (pun intented) than methods. len(ob) checks that ob.__len__() returns an int or something that can be 'interpreted' as such. reversed(itable) checks for itable.__reversed__ before using a default version. -- Terry Jan Reedy From greg at krypto.org Sun Dec 1 03:03:21 2013 From: greg at krypto.org (Gregory P. Smith) Date: Sat, 30 Nov 2013 18:03:21 -0800 Subject: [Python-ideas] Replacing the if __name__ == "__main__" idiom (was Re: making a module callable) In-Reply-To: References: <20131125071932.GA65531@cskk.homeip.net> <20131125141220.GE2085@ando> <20131125144244.1cb160f0@anarchist>

<20131125171603.1812e9fd@anarchist>

<5294CD94.6050008@gmail.com>

Message-ID: On Wed, Nov 27, 2013 at 9:58 AM, Gregory Salvan wrote: > my cent: > I think it's most often a bad practice (whereas it's convenient) to mix > "executable" and "importable" code. > Providing an easier way to do it, may encourage a bad practice. > > I would prefer a solution which encourage separation of "executable" and > "importable" code. > The only way to do that is to force people to put their executable code in a __main__.py file and prevent class and function definitions within that... Gross. People need the test for main or not (imported or not) because they write unit tests for _all_ of their code, including their main program. Just because it can be imported does not mean it is a library that anyone outside of their tests _should_ import. Sure, there are some python stdlib modules and others that work as an importable library or via python -m modulename to run a program but I wouldn't call that the common case. I would not want that to stop working either. -gps > > > > 2013/11/26 Andrew Barnert > >> On Nov 26, 2013, at 8:34, Alan Cristhian Ruiz >> wrote: >> >> > I think the need to change * if __ name__ == "__main__": * is >> capricious and obsessive. The current rule is better than anything that has >> been suggested so far. I never had any problems with the * if __ name__ == >> "__main__": *. Also in python there are other things much more difficult to >> learn and use, such as metaclasses. >> >> Although I agree with your main point, I don't think that's a very good >> argument. >> >> __main__ is something novices have to learn early and use in code >> regularly; metaclasses are something only experienced developers use, and >> not that often (and that's even if you count using stdlib metaclasses to, >> e.g., create ABCs, which doesn't really require you to understand how they >> work). It's perfectly reasonable for an "expert" feature to be more >> difficult to learn than a novice feature. >> >> Also, Python doesn't have a queue of improvements to be scheduled to a >> team of developers. Things get improved if someone is motivated enough to >> write the code and drive the idea to consensus and/or BDFL approval. So, >> improving this would have very little bearing on improving things you care >> about more. >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > https://mail.python.org/mailman/listinfo/python-ideas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at krypto.org Sun Dec 1 03:04:05 2013 From: greg at krypto.org (Gregory P. Smith) Date: Sat, 30 Nov 2013 18:04:05 -0800 Subject: [Python-ideas] Replacing the if __name__ == "__main__" idiom (was Re: making a module callable) In-Reply-To: References: <20131125071932.GA65531@cskk.homeip.net> <20131125141220.GE2085@ando> Message-ID: On Mon, Nov 25, 2013 at 6:22 AM, Nick Coghlan wrote: > On 26 November 2013 00:12, Steven D'Aprano wrote: > > > > I'm wondering if we should add a link to Steven's post from > http://www.python.org/dev/peps/pep-0299/ (and perhaps even update the > PEP text itself) > > As the status of PEP 299 shows, Guido has rejected the idea of a > special main function before, but I think Steven's post does a better > job of spelling out "Why not?" than any of the previous discussions. > +1 (if you haven't already done it) -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarnert at yahoo.com Sun Dec 1 05:33:08 2013 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 30 Nov 2013 20:33:08 -0800 Subject: [Python-ideas] string codes & substring equality In-Reply-To: References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz>

Message-ID: <6751972E-5222-4B02-AD87-3FBC404C1317@yahoo.com> On Nov 30, 2013, at 15:48, Guido van Rossum wrote: > > On Sat, Nov 30, 2013 at 3:42 PM, Andrew Barnert wrote: >> On Nov 28, 2013, at 22:49, Greg Ewing wrote: >> >>> spir wrote: >>>> (But then, possibly, some would wonder why this new ord(s,i) is not a string method ;-) >>> >>> For the same reason that the existing ord() function isn't >>> a string method, whatever that is! >> >> http://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list >> >> The short version is: historical reasons, and no reason to change it compelling enough to be worth the costs in backward compat, bikeshedding, etc. > > That FAQ entry does not do the real motivation justice. While OO "purists" may argue about it, to me it's obvious that in quite a few cases the function spelling is more readable than the method spelling. I found it more readable 23 years ago, and I still find it more readable today. So it's not historical reasons to me, even if not everybody agrees (obviously :-). I kind of read it the other way around--making _too many_ things methods is the historical quirk, because at some point (probably after making str and tuple and so on into full types) you and the other core devs went a bit farther with the OO-style "everything should be a method if at all possible" than you would have earlier or later in history. But I may have been assuming too much. A lot of other "multi-paradigm" languages went through a phase like that and have a historical legacy, like C++'s ridiculous string class and JavaScript's excess of Array methods. But Python does seen to have ended up with a lot fewer quirky choices than those languages. Still, I think the various index/find/count/etc. methods didn't all need to be methods. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sun Dec 1 06:03:51 2013 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 1 Dec 2013 15:03:51 +1000 Subject: [Python-ideas] string codes & substring equality In-Reply-To: <6751972E-5222-4B02-AD87-3FBC404C1317@yahoo.com> References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz>

<6751972E-5222-4B02-AD87-3FBC404C1317@yahoo.com> Message-ID: On 1 December 2013 14:33, Andrew Barnert wrote: > On Nov 30, 2013, at 15:48, Guido van Rossum wrote: > That FAQ entry does not do the real motivation justice. While OO "purists" > may argue about it, to me it's obvious that in quite a few cases the > function spelling is more readable than the method spelling. I found it more > readable 23 years ago, and I still find it more readable today. So it's not > historical reasons to me, even if not everybody agrees (obviously :-). > > I kind of read it the other way around--making _too many_ things methods is > the historical quirk, because at some point (probably after making str and > tuple and so on into full types) you and the other core devs went a bit > farther with the OO-style "everything should be a method if at all possible" > than you would have earlier or later in history. > > But I may have been assuming too much. A lot of other "multi-paradigm" > languages went through a phase like that and have a historical legacy, like > C++'s ridiculous string class and JavaScript's excess of Array methods. But > Python does seen to have ended up with a lot fewer quirky choices than those > languages. Still, I think the various index/find/count/etc. methods didn't > all need to be methods. One of the other things to keep in mind is that many of the builtin function vs method choices predated the iterator protocol. A few have since been updated to work with it (list.sort -> sorted, list.reverse -> reversed), but others live on as Sequence ABC methods rather than as builtins or itertools. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From abarnert at yahoo.com Sun Dec 1 06:53:54 2013 From: abarnert at yahoo.com (Andrew Barnert) Date: Sat, 30 Nov 2013 21:53:54 -0800 Subject: [Python-ideas] string codes & substring equality In-Reply-To: References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz>

<6751972E-5222-4B02-AD87-3FBC404C1317@yahoo.com> Message-ID: On Nov 30, 2013, at 21:03, Nick Coghlan wrote: > On 1 December 2013 14:33, Andrew Barnert wrote: >> On Nov 30, 2013, at 15:48, Guido van Rossum wrote: >> That FAQ entry does not do the real motivation justice. While OO "purists" >> may argue about it, to me it's obvious that in quite a few cases the >> function spelling is more readable than the method spelling. I found it more >> readable 23 years ago, and I still find it more readable today. So it's not >> historical reasons to me, even if not everybody agrees (obviously :-). >> >> I kind of read it the other way around--making _too many_ things methods is >> the historical quirk, because at some point (probably after making str and >> tuple and so on into full types) you and the other core devs went a bit >> farther with the OO-style "everything should be a method if at all possible" >> than you would have earlier or later in history. >> >> But I may have been assuming too much. A lot of other "multi-paradigm" >> languages went through a phase like that and have a historical legacy, like >> C++'s ridiculous string class and JavaScript's excess of Array methods. But >> Python does seen to have ended up with a lot fewer quirky choices than those >> languages. Still, I think the various index/find/count/etc. methods didn't >> all need to be methods. > > One of the other things to keep in mind is that many of the builtin > function vs method choices predated the iterator protocol. A few have > since been updated to work with it (list.sort -> sorted, list.reverse > -> reversed), but others live on as Sequence ABC methods rather than > as builtins or itertools. Sure, that's the part of "historical reasons" that seems accurate. There are a few methods that would be functions if they were added today (e.g., because the iterator protocol didn't exist), and a few functions that might be methods (e.g., because some of the standard types weren't class-like). Many of them would be the same even if they were added today; it's only the handful of exceptions that people even think to ask about. If you read the FAQ as saying that Python should be Java/Ruby-style pure OO (or that it should be Haskell-style pure functional), but isn't because of historical reasons, then it's unfair and incorrect. But I just read it as saying the exact balance of methods vs. functions might turn out slightly different. From denis.spir at gmail.com Sun Dec 1 09:15:41 2013 From: denis.spir at gmail.com (spir) Date: Sun, 01 Dec 2013 09:15:41 +0100 Subject: [Python-ideas] string codes & substring equality In-Reply-To: References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz> Message-ID: <529AF02D.5080007@gmail.com> On 12/01/2013 12:42 AM, Andrew Barnert wrote: > On Nov 28, 2013, at 22:49, Greg Ewing wrote: > >> spir wrote: >>> (But then, possibly, some would wonder why this new ord(s,i) is not a string method ;-) >> >> For the same reason that the existing ord() function isn't >> a string method, whatever that is! > > http://docs.python.org/2/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list > > The short version is: historical reasons, and no reason to change it compelling enough to be worth the costs in backward compat, bikeshedding, etc. I'm very ok with extending the builtin func ord to get an index param: ord(i). Solves the issue without trouble, and backward compatibile. What do you think? Denis From denis.spir at gmail.com Sun Dec 1 09:21:59 2013 From: denis.spir at gmail.com (spir) Date: Sun, 01 Dec 2013 09:21:59 +0100 Subject: [Python-ideas] string codes & substring equality In-Reply-To: References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz>

Message-ID: <529AF1A7.4090803@gmail.com> On 12/01/2013 12:48 AM, Guido van Rossum wrote: > That FAQ entry does not do the real motivation justice. While OO "purists" > may argue about it, to me it's obvious that in quite a few cases the > function spelling is more readable than the method spelling. I found it > more readable 23 years ago, and I still find it more readable today. So > it's not historical reasons to me, even if not everybody agrees (obviously > :-). I was told ord() is a func because it works only on single-code (historically single-byte) strings (yes, ord throws an error otherwise, I just checked!). From a personal, nearly esthetic, pov, I'd rather make ord a method [s.ord(i)], and join not [join(strings, sep)]. But I do _not_ want to argue on this ;-). Denis From denis.spir at gmail.com Sun Dec 1 09:37:24 2013 From: denis.spir at gmail.com (spir) Date: Sun, 01 Dec 2013 09:37:24 +0100 Subject: [Python-ideas] string codes & substring equality In-Reply-To: <6751972E-5222-4B02-AD87-3FBC404C1317@yahoo.com> References: <52960290.6090809@gmail.com> <52972C49.1040909@gmail.com> <20131129004527.GZ2085@ando> <52981EB6.50003@canterbury.ac.nz> <52983764.9010204@gmail.com> <5298390B.30506@canterbury.ac.nz>