Re: coding style - where to declare variables

On Mon, 23 Jul 2018 14:39:56 +0300, Marko Rauhamaa wrote: > Steven D'Aprano : > >> Lambda calculus has the concept of a binding operator, which is >> effectively an assignment operator: it takes a variable and a value and >> binds the value to the variable, changing a free variable to a bound >>

Re: coding style - where to declare variables

On Mon, Jul 23, 2018 at 9:39 PM, Steven D'Aprano wrote: > [1] The CPython interpreter uses pointers; the Jython interpreter uses > whatever kind of memory indirection the JVM provides; when I emulate a > Python interpreter using pencil and paper, there's not a pointer in sight > but a lot of copyi

Re: coding style - where to declare variables

On Mon, 23 Jul 2018 09:22:55 +0300, Marko Rauhamaa wrote: > Dennis Lee Bieber : [...] >> In my world, Java and Python are the ones that are not "common". > > Yes, "boxed" is a Java term. However, the programming pattern of using > dynamic memory and pointers is ubiquitous and ancient: Not t

Re: coding style - where to declare variables

Steven D'Aprano : > Lambda calculus has the concept of a binding operator, which is > effectively an assignment operator: it takes a variable and a value > and binds the value to the variable, changing a free variable to a > bound variable. In other words, it assigns the value to the variable, > j

Re: coding style - where to declare variables

On Mon, 23 Jul 2018 11:49:37 +0300, Marko Rauhamaa wrote: > People new to Python are unnecessarily confused by talking about names > and binding when it's really just ordinary variables and assignment. It really isn't, not to those people who expect ordinary variables and assignment to be the sa

Re: coding style - where to declare variables

Mark Lawrence writes: > On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote: >> except local vars >> >> Abdur-Rahmaan Janhangeer >> https://github.com/Abdur-rahmaanJ >> Mauritius >> > > Python doesn't have variables, it has names. I think we should cut beginners (and probably everyone) some slack

Re: coding style - where to declare variables

On Mon, 23 Jul 2018 20:24:30 +1200, Gregory Ewing wrote: > Steven D'Aprano wrote: >> So let me see if I understand your argument... >> >> - we should stop using the term "binding", because it means >> nothing different from assignment; >> - binding (a.k.a. "assignment") comes from lambda calcul

Re: coding style - where to declare variables

"Marko Rauhamaa" wrote in message news:87zhyitjz2@elektro.pacujo.net... People new to Python are unnecessarily confused by talking about names and binding when it's really just ordinary variables and assignment. It seems to be mostly some sort of marketing lingo that seeks to create an air

Re: coding style - where to declare variables

Ben Finney : > Gregory Ewing writes: > >> Marko is asking us to stop using the word "binding" to refer to >> assignment because of the potential confusion with this other meaning. > > That's about as reasonable as my request that we stop using the term > “variable” for what is, in Python, an un-ty

Re: coding style - where to declare variables

Gregory Ewing writes: > Marko is asking us to stop using the word "binding" to refer to > assignment because of the potential confusion with this other meaning. That's about as reasonable as my request that we stop using the term “variable” for what is, in Python, an un-typed reference to an obj

Re: coding style - where to declare variables

Steven D'Aprano wrote: So let me see if I understand your argument... - we should stop using the term "binding", because it means nothing different from assignment; - binding (a.k.a. "assignment") comes from lambda calculus; - which has no assignment (a.k.a. "binding"). No, that's not what

Re: coding style - where to declare variables

Dennis Lee Bieber : > On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa > declaimed the following: > >>I Java terms, all Python values are boxed. That's a very usual pattern >>in virtually all programming languages (apart from FORTRAN). > > FORTRAN, C, COBOL, BASIC, Pascal, ALGOL, BCPL, REX

Re: coding style - where to declare variables

variables here refers to the user experience of a var np, just a link to the thread/s would mark the end of it Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Mauritius -- https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

On 22/07/18 14:51, Abdur-Rahmaan Janhangeer wrote: except local vars Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Mauritius Python doesn't have variables, it has names. Please can we avoid a long meaningless thread on this subject as it's been discussed a trillion times befor

Re: coding style - where to declare variables

On Sun, 22 Jul 2018 17:50:06 -0400, Dennis Lee Bieber wrote: > On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa > declaimed the following: > >>I Java terms, all Python values are boxed. That's a very usual pattern >>in virtually all programming languages (apart from FORTRAN). >> >> > FOR

Re: coding style - where to declare variables

On Mon, 23 Jul 2018 00:08:00 +0300, Marko Rauhamaa wrote: > Would you call it binding in this case: > >X[0]["z"] = getit() >X[3]["q"] = X[0]["z"] >X[0]["z"].changeit() It is a binding, but it is not a *name* binding. Since we are talking about name bindings, and comparing/contrastin

Re: coding style - where to declare variables

On Sun, 22 Jul 2018 22:50:52 +0300, Marko Rauhamaa wrote: > I wish people stopped talking about "name binding" and "rebinding," > which are simply posh synonyms for variable assignment. Properly, the > term "binding" comes from lambda calculus, whose semantics is defined > using "bound" and "free"

Re: coding style - where to declare variables

Richard Damon : >> On Jul 22, 2018, at 3:50 PM, Marko Rauhamaa wrote: >> I wish people stopped talking about "name binding" and "rebinding," >> which are simply posh synonyms for variable assignment. Properly, the >> term "binding" comes from lambda calculus, whose semantics is defined >> using "

Re: coding style - where to declare variables

On Mon, Jul 23, 2018 at 6:14 AM, Marko Rauhamaa wrote: > While FORTRAN or C couldn't operate on functions like this, an assembly > language program could easily. Simply compose a CPU instruction sequence > on the fly, mark it executable and use the "CALL" opcode to transfer > control to your const

Re: coding style - where to declare variables

Bart : > If you did need one of those others to be variable, then you just assign > it to a variable the rare times you need to do that. For example: > > def fn1(): pass > def fn2(): pass > > fn = fn1 if cond else fn2 > > fn1, fn2 will always be functions. fn will always be a variable, but on

Re: coding style - where to declare variables

> On Jul 22, 2018, at 3:50 PM, Marko Rauhamaa wrote: > I wish people stopped talking about "name binding" and "rebinding," > which are simply posh synonyms for variable assignment. Properly, the > term "binding" comes from lambda calculus, whose semantics is defined > using "bound" and "free" var

Re: coding style - where to declare variables

r...@zedat.fu-berlin.de (Stefan Ram): >>Rebinding names is near-universal in programming, but usually names >>that are intended to be rebound, such as variables. > > To someone like me who has grown up with a LISP 1 > this is completely natural. > > |>( SETQ A ( LAMBDA () 'ALPHA )) > |(LAMBDA (

Re: coding style - where to declare variables

On 2018-07-22 09:36:13 -0400, Richard Damon wrote: > > On Jul 22, 2018, at 8:48 AM, Sharan Basappa > > wrote: > > > > In other programming languages (e.g. C, C++), as a good practice, > > variables are declared right at the start of the program, There is no "start of the program" in C or C++. I

Re: coding style - where to declare variables

except local vars Abdur-Rahmaan Janhangeer https://github.com/Abdur-rahmaanJ Mauritius -- https://mail.python.org/mailman/listinfo/python-list

Re: coding style - where to declare variables

On Sun, Jul 22, 2018 at 10:48 PM, Sharan Basappa wrote: > In other programming languages (e.g. C, C++), as a good practice, variables > are declared right at the start of the program, irrespective of where it is > normally used. What is the practice in Python? > > I see that, most of the code, d

Re: coding style - where to declare variables

> On Jul 22, 2018, at 8:48 AM, Sharan Basappa wrote: > > In other programming languages (e.g. C, C++), as a good practice, variables > are declared right at the start of the program, irrespective of where it is > normally used. What is the practice in Python? > > I see that, most of the code

coding style - where to declare variables

In other programming languages (e.g. C, C++), as a good practice, variables are declared right at the start of the program, irrespective of where it is normally used. What is the practice in Python? I see that, most of the code, declare variables where it is used and not at the start of the pro

Re: Coding style in CPython implementation

On 28/10/17 19:42, Στέφανος Σωφρονίου wrote: Greetings everyone. I have noticed that in many if conditions the following syntax is used: a) if (variable == NULL) { ... } b) if (variable == -1) { ... } c) if (variable != NULL) { ... } What I wanted to ask is, is there a particular reason for no

Re: Coding style in CPython implementation

On Monday, October 30, 2017 at 2:35:13 AM UTC+2, ROGER GRAYDON CHRISTMAN wrote: > NOTE: The case in question was never comparing to True; it was comparing to > NULL. > > There is no "No: if x == None" below, because None is not Boolean. > Similarly comparing a pointer to NULL is not the same as

Re: Coding style in CPython implementation

NOTE: The case in question was never comparing to True; it was comparing to NULL. There is no "No: if x == None" below, because None is not Boolean. Similarly comparing a pointer to NULL is not the same as comparing it to a Boolean. So I would favor the "Explicit is better than Implicit" in th

Re: Coding style in CPython implementation

On Mon, Oct 30, 2017 at 12:47 AM, Stefan Ram wrote: > =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?= > writes: >>I guess the following parts from "Zen of Python" apply to this case: > > If we would agree to apply Python rules to C, > then we could also use this excerpt from PEP

Re: Coding style in CPython implementation

On Sunday, October 29, 2017 at 4:00:59 AM UTC-5, Στέφανος Σωφρονίου wrote: [...] > I guess the following parts from "Zen of Python" apply to this case: > > - Beautiful is better than ugly. > - Explicit is better than implicit. > - Simple is better than complex. > - Readability counts. Now go

Re: Coding style in CPython implementation

On Sunday, October 29, 2017 at 4:18:38 AM UTC+2, Dan Sommers wrote: > On Sat, 28 Oct 2017 16:20:54 -0700, Στέφανος Σωφρονίου wrote: > > > I do believe though that if (!d) is a lot clearer than if (d == NULL) > > as it is safer than falsely assigning NULL in d, by pure mistake. > > Having made my

Re: Coding style in CPython implementation

On Sat, 28 Oct 2017 16:20:54 -0700, Στέφανος Σωφρονίου wrote: > I do believe though that if (!d) is a lot clearer than if (d == NULL) > as it is safer than falsely assigning NULL in d, by pure mistake. Having made my living writing C code for a very long time, I always found if (!d) *harder* to r

Re: Coding style in CPython implementation

to assign -1 to variable > > in case of an accidental mistyping of equals sign; it had happened > > countless times by now to to many of us that use various C-family languages. > > > > Is there a particular reason for using this specific coding style? > > Which one do you think

Re: Coding style in CPython implementation

only the meaning that usually is intended if one of the headers needed for it has been »#include«d. The operator »!« and the if-statement do not require any »#include«. I certainly wouldn't adjust my coding style to avoid #include'ing the definition of NULL. --Ned

Re: Coding style in CPython implementation

On 10/28/17 3:00 PM, Stefan Ram wrote: =?UTF-8?B?zqPPhM6tz4bOsc69zr/PgiDOo8+Jz4bPgc6/zr3Or86/z4U=?= writes: What I wanted to ask is, is there a particular reason for not choosing I am not a CPython developer, but here are my 2 cents about the possibilities: if (variable == NULL) { ...

Re: Coding style in CPython implementation

; > Especially the (b) syntax is extremely dangerous to assign -1 to variable in > case of an accidental mistyping of equals sign; it had happened countless > times by now to to many of us that use various C-family languages. > > Is there a particular reason for using this specific co

Re: Coding style in CPython implementation

extremely dangerous to assign -1 to variable in case of an accidental mistyping of equals sign; it had happened countless times by now to to many of us that use various C-family languages. Is there a particular reason for using this specific coding style? Which one do you think is more readable

Coding style in CPython implementation

; it had happened countless times by now to to many of us that use various C-family languages. Is there a particular reason for using this specific coding style? Regards, Stefanos -- https://mail.python.org/mailman/listinfo/python-list

Re: Basic question about speed/coding style/memory

Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道： > On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers > wrote: > > Block > > #-- > > if statemente_true: > > doSomething() > > else: > > doSomethingElseInstead() > > > > #--

Re: Basic question about speed/coding style/memory

Jan Riechers於 2012年7月21日星期六UTC+8下午3時33分27秒寫道： > Hello Pythonlist, > > I have one very basic question about speed,memory friendly coding, and > coding style of the following easy "if"-statement in Python 2.7, > but Im > sure its also the s

Re: Basic question about speed/coding style/memory

On Sat, Jul 21, 2012 at 5:06 AM, Steven D'Aprano wrote: > So there is approximately 0.03 second difference per TWO MILLION > if...else blocks, or about 15 nanoseconds each. This is highly unlikely > to be the bottleneck in your code. Assuming the difference is real, and > not just measurement erro

Re: Basic question about speed/coding style/memory

Jan Riechers wrote: > I have one very basic question about speed,memory friendly coding, and > coding style of the following easy "if"-statement in Python 2.7, but Im > sure its also the same in Python 3.x > > Block > #-- > if

Re: Basic question about speed/coding style/memory

On 21.07.2012 12:06, Steven D'Aprano wrote: But in general, you're worrying too much about trivia. One way or the other, any speed difference will be trivial. Write whatever style reads and writes most naturally, and only worry about what's faster where it actually counts. Notice that I try

Re: Basic question about speed/coding style/memory

On Sat, 21 Jul 2012 10:33:27 +0300, Jan Riechers wrote: > Hello Pythonlist, > > I have one very basic question about speed,memory friendly coding, and > coding style of the following easy "if"-statement in Python 2.7, but Im > sure its also the same in Python 3.x I ass

Re: Basic question about speed/coding style/memory

On 7/21/2012 3:13 AM, Jan Riechers wrote: > Cause, as I understand the interpreter chooses either the "else" (1st > block) or just proceeds with following code outside the if. If none of the if/elif statements evaluate to something true, the else block is executed. > So if there is some overhead

Re: Basic question about speed/coding style/memory

On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers wrote: > Block > #-- > if statemente_true: > doSomething() > else: > doSomethingElseInstead() > > #-- This means, to me, that the two options are peers - you do this or yo

Re: Basic question about speed/coding style/memory

On 21.07.2012 11:02, Andrew Berg wrote: On 7/21/2012 2:33 AM, Jan Riechers wrote: Block ... versus this block: ... Now, very briefly, what is the better way to proceed in terms of execution speed, readability, coding style? Using if/else is the most readable in the general sense. Using return

Re: Basic question about speed/coding style/memory

On 7/21/2012 2:33 AM, Jan Riechers wrote: > Block > ... > versus this block: > ... > Now, very briefly, what is the better way to proceed in terms of > execution speed, readability, coding style? Using if/else is the most readable in the general sense. Using return (or br

Basic question about speed/coding style/memory

Hello Pythonlist, I have one very basic question about speed,memory friendly coding, and coding style of the following easy "if"-statement in Python 2.7, but Im sure its also the same in Python 3.x Block #-- if statemente_true: doSometh

Re: Suggested coding style

On 9/30/11 6:54 AM, rantingrick wrote: > a misplaced and rarely used functionality of the stdlib. Have you tried putting "\.zfill\(" and selecting Python in google.com/codesearch? It seems to have quite a few users, among only openly available code. Considering there is a much larger body of code

Re: Suggested coding style

> > On Sep 29, 10:23 pm, rantingrick wrote: > > > What is so bad about breaking code in obscure places? > On Sep 29, 9:50 pm, alex23 wrote: > > Try coding in PHP across minor release versions and see how you feel > > about deprecating core functions on a whim. On Sep 30, 11:54 pm, rantingrick

Re: Suggested coding style

Meh, so run your own web-server. If wave isn't right, search on sourceforge for a while. On 10/1/11, Prasad, Ramit wrote: >>> The answer to any news/mail client with feature X type question is >>> normally "gnus" - although I don't know what "Gmail-like style" is. >>Yeah > > Gah, I got distracte

RE: Suggested coding style

>> The answer to any news/mail client with feature X type question is >> normally "gnus" - although I don't know what "Gmail-like style" is. >Yeah Gah, I got distracted mid-email and forgot to finish. What I wanted to say was, "Yeah, not knowing what 'Gmail-like style' makes a big difference ;)"

RE: Suggested coding style

May I suggest a[n] email client that can group mailing list threads? > The answer to any news/mail client with feature X type question is > normally "gnus" - although I don't know what "Gmail-like style" is. Yeah >slrn. Is good. Unless I am missing something, it does not do email. >http://in

Re: Suggested coding style

http://incubator.apache.org/wave/ On 10/1/11, Neil Cerutti wrote: > On 2011-09-30, Paul Rudin wrote: >> "Prasad, Ramit" writes: >> May I suggest a[n] email client that can group mailing list threads? >>> >>> Please do. Bonus points if it handles threading in a Gmail-like style. >> >> The an

Re: Suggested coding style

On 2011-09-30, Paul Rudin wrote: > "Prasad, Ramit" writes: > >>>May I suggest a[n] email client that can group mailing list threads? >> >> Please do. Bonus points if it handles threading in a Gmail-like style. > > The answer to any news/mail client with feature X type question is > normally "gnus

Re: Suggested coding style

Maybe one Apache's Buzz? On 10/1/11, Prasad, Ramit wrote: >>> Please do. Bonus points if it handles threading in a Gmail-like style. >>> >> >>May I suggest Gmail? It handles threading in a very Gmail-like style. > > Curses, foiled by my lack of specificity! I meant desktop client. > Although...if

Re: Suggested coding style

"Prasad, Ramit" writes: >>May I suggest a[n] email client that can group mailing list threads? > > Please do. Bonus points if it handles threading in a Gmail-like style. The answer to any news/mail client with feature X type question is normally "gnus" - although I don't know what "Gmail-like st

Re: Suggested coding style

On Sat, Oct 1, 2011 at 3:05 AM, Prasad, Ramit wrote: > Curses, foiled by my lack of specificity! I meant desktop client. > Although...if another website does similar threading it would be good to > know. Never know when I will want to start avoiding Gmail :) > Ah, *desktop* client! Hm. I actual

RE: Suggested coding style

>> Please do. Bonus points if it handles threading in a Gmail-like style. >> > >May I suggest Gmail? It handles threading in a very Gmail-like style. Curses, foiled by my lack of specificity! I meant desktop client. Although...if another website does similar threading it would be good to know. Ne

Re: Suggested coding style

On Sat, Oct 1, 2011 at 2:06 AM, Prasad, Ramit wrote: >>May I suggest a[n] email client that can group mailing list threads? > > Please do. Bonus points if it handles threading in a Gmail-like style. > May I suggest Gmail? It handles threading in a very Gmail-like style. ChrisA running and duckin

RE: Suggested coding style

423 -Original Message- From: python-list-bounces+ramit.prasad=jpmorgan@python.org [mailto:python-list-bounces+ramit.prasad=jpmorgan@python.org] On Behalf Of Devin Jeanpierre Sent: Thursday, September 29, 2011 6:07 PM To: rantingrick Cc: python-list@python.org Subject: Re: Suggested coding st

Re: Suggested coding style

On Fri, Sep 30, 2011 at 11:54 PM, rantingrick wrote: > Well "alex", like yourself, i hold expertise in many fields BESIDES > programming. One of which being psychology. > I *knew* it! We're all part of a huge experiment to see how much the human psyche can withstand. If we succeed on the Rick tes

Re: Suggested coding style

Note: I am quoting "Passiday" to get this thread back on subject however my reply is for "alex23" the philosopher" On Sep 29, 9:50 pm, alex23 wrote: > On Sep 29, 10:23 pm, rantingrick wrote: > > > What is so bad about breaking code in obscure places? > > Try coding in PHP across minor release ve

Re: Suggested coding style

On Sep 29, 11:49 pm, Ian Kelly wrote: > Nope, that doesn't work. > > >>> "{0:0>10}".format("-1234") > > '0-1234' > > The whole point of zfill is that it handles signs correctly. py> "{0:-010d}".format(-1234) '-01234' My point was: Use the {char}{repeat}d format for integers and the {char

Re: Suggested coding style

On Fri, Sep 30, 2011 at 4:14 PM, Westley Martínez wrote: > I'm one of the weirdos who is absolutely hostile to the format method > and continues to use % formatting.  I'm pretty sure it is because of my > C background (actually I learned Python before C, and thus learned % > formatting in Python).

Re: Suggested coding style

On Thu, Sep 29, 2011 at 07:07:28PM -0400, Devin Jeanpierre wrote: > > However, as you use the new format method you will come to appreciate > > it. It's an adult beverage with an acquired taste. ;-) > > Yeah. It's a much more difficult to read thing, but once you learn how > to write it it flows f

Re: Suggested coding style

On Sep 30, 3:14 pm, Ben Finney wrote: > alex23 writes: > > On Sep 29, 10:23 pm, rantingrick wrote: > > > GvR should be texting me every night in hopes that some of my API > > > genius will rub off on him. > > > Are you off your medication again? > > Please don't make personal attacks. If you don

Re: Suggested coding style

alex23 writes: > On Sep 29, 10:23 pm, rantingrick wrote: > > GvR should be texting me every night in hopes that some of my API > > genius will rub off on him. > > Are you off your medication again? Please don't make personal attacks. If you don't feel like addressing the content of his message

Re: Suggested coding style

On Thu, Sep 29, 2011 at 4:56 PM, rantingrick wrote: >> Agree that zfill seems to be redundant with str.format, although your >> suggested syntax is atrocious, especially since a syntax already >> exists that fits better in the already-complicated format specifier >> syntax. > > It's interesting th

Re: Suggested coding style

On Thu, Sep 29, 2011 at 5:47 PM, rantingrick wrote: > Ah ha! Found the answer! > > py> "{0:010d}".format(1234) > 001234 > > py> "{0:0>10}".format(1234) > 001234 > > py> "{0:0>10}".format("1234") > 001234 > > py> "{0:@>10}".format("1234") > @@1234 > > I would skip using the "{int}{r

Re: Benefit and belief [was Re: Suggested coding style]

Dennis Lee Bieber wrote: >         Well... We could try for equality in offense -- the Torah or the > Koran? Maybe the Tripitaka or Sutras? I always enjoyed the possibly apocryphal claim that the design of VRML was influenced by the story of Indra's Net. Maybe some religious tomes are just better

Re: Suggested coding style

On Fri, Sep 30, 2011 at 12:50 PM, alex23 wrote: >> GvR should be texting me every night in hopes that some of my API genius >> will rub >> off on him. > > Are you off your medication again? > He's very much like jimontrack (aka Tranzit Jim - google him if you're curious), whose username people f

Re: Suggested coding style

On Sep 29, 5:12 pm, Ian Kelly wrote: > On Thu, Sep 29, 2011 at 6:23 AM, rantingrick wrote: > > A specific method for padding a string with ONLY zeros is ludicrous > > and exposes the narrow mindedness of the creator. The only thing worse > > than "zfill" as a string method is making zfill into bu

Re: Suggested coding style

On Sep 29, 6:07 pm, Devin Jeanpierre wrote: > > However, as you use the new format method you will come to appreciate > > it. It's an adult beverage with an acquired taste. ;-) > > Yeah. It's a much more difficult to read thing, but once you learn how > to write it it flows faster. > > Of course,

Re: Suggested coding style

> However, as you use the new format method you will come to appreciate > it. It's an adult beverage with an acquired taste. ;-) Yeah. It's a much more difficult to read thing, but once you learn how to write it it flows faster. Of course, I never managed to learn how to write it... I would sugg

Re: Suggested coding style

On Sep 29, 5:12 pm, Ian Kelly wrote: > On Thu, Sep 29, 2011 at 6:23 AM, rantingrick wrote: > > A specific method for padding a string with ONLY zeros is ludicrous > > and exposes the narrow mindedness of the creator. The only thing worse > > than "zfill" as a string method is making zfill into bu

Re: Suggested coding style

On Thu, Sep 29, 2011 at 6:23 AM, rantingrick wrote: > A specific method for padding a string with ONLY zeros is ludicrous > and exposes the narrow mindedness of the creator. The only thing worse > than "zfill" as a string method is making zfill into built-in > function! The ONLY proper place for z

Re: Suggested coding style

Passiday writes: > Oh, my. Who could expect this topic would iterate to some whining > about religion (please don't respond on this remark of mine). That's an unreasonable request. If you make a provocative remark (I doubt you chose to use “whining” without knowing how dismissive it is), it's di

Re: Suggested coding style

On Fri, Sep 30, 2011 at 2:42 AM, Westley Martínez wrote: > But maybe I'm just batty as you all think I am. Yes, I'm afraid so. Bonkers. Off your head. But let me tell you a secret... All the best people are. > Well, I once thought that a print function made a lot of sense.  In C, > printf is a f

Re: Suggested coding style

On Thu, Sep 29, 2011 at 05:23:30AM -0700, rantingrick wrote: > On Sep 29, 5:37 am, Passiday wrote: > > What is so bad about breaking code in obscure places? We changed print > to a function which broke just about every piece of code every written > in this language. (BTW, print should ALWAYS hav

Re: Suggested coding style

On Thu, Sep 29, 2011 at 08:37:53PM +1000, Steven D'Aprano wrote: > Westley Martínez wrote: > > > Perhaps you should spend a little less time on the mailing list and a > > little more time in church. > > Is that meant as punishment for Rick or for the churchgoers? > > Hopefully neither, probabl

Re: Suggested coding style

On Sep 29, 7:23 am, rantingrick wrote: > A specific method for padding a string with ONLY zeros is ludicrous > and exposes the narrow mindedness of the creator. The only thing worse > than "zfill" as a string method is making zfill into built-in > function! The ONLY proper place for zfill is as a

Re: Suggested coding style

point of all this, yes. You see, around here, once the point is made there is an unwritten rule that the thread must then descend into chaos. However, it seems you "may" have brought this train wreck back to reality below... whether the trolls will allow that happen remains to be seen...?

Re: Suggested coding style

some good guidelines: http://www.python.org/dev/peps/pep-0008 My topic was "Suggested coding style" because I hoped there is some common understanding which of the ancient methods/functions are so not where they should be that the use of them should be depreciated. I can fully under

Re: Suggested coding style

Westley Martínez wrote: > Perhaps you should spend a little less time on the mailing list and a > little more time in church. Is that meant as punishment for Rick or for the churchgoers? -- Steven -- http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

On Thu, Sep 29, 2011 at 12:57 AM, Ian Kelly wrote: > On Thu, Sep 29, 2011 at 12:24 AM, Westley Martínez wrote: >> Perhaps you should spend a little less time on the mailing list and a >> little more time in church. > > You must not like churchgoers very much if you want to inflict > rantingrick o

Re: Suggested coding style

On Thu, Sep 29, 2011 at 12:24 AM, Westley Martínez wrote: > Perhaps you should spend a little less time on the mailing list and a > little more time in church. You must not like churchgoers very much if you want to inflict rantingrick on them... -- http://mail.python.org/mailman/listinfo/python-

Re: Suggested coding style

On Wed, Sep 28, 2011 at 07:11:08PM -0700, rantingrick wrote: > On Sep 28, 6:26 pm, Tim Johnson wrote: > > * DevPlayer [110928 04:31]: > > > On Sep 27, 10:25 pm, alex23 wrote: > > > > rantingrick wrote: > > > > > Since, like the bible > > > > > the zen is self contradicting, any argument utilizi

Re: Suggested coding style

On Sep 28, 10:12 pm, DevPlayer wrote: > Calling the Bible a joke is used to hurt people, not enlighten them. Y'know, I wouldn't even bother responding to this if Xianists were as open, forgiving and accepting as their messiah told them to be. It was a *flippant remark*. If you want to establish i

Re: Suggested coding style

etter: Suggested coding style Options -- http://mail.python.org/mailman/listinfo/python-list

Re: Suggested coding style

On Sep 28, 6:26 pm, Tim Johnson wrote: > * DevPlayer [110928 04:31]: > > On Sep 27, 10:25 pm, alex23 wrote: > > > rantingrick wrote: > > > > Since, like the bible > > > > the zen is self contradicting, any argument utilizing the zen can be > > > > defeated utilizing the zen. > > > > And like th

Re: [OT] Benefit and belief [was Re: Suggested coding style]

> Forget money, or even the love of money. The idea that one mustn't > criticise another person's beliefs is the root of all evil. This was a technical discussion, and calling the bible a joke was not necessary at all. It creates a hostile atmosphere. Can't you pick somewhere else to attack Chris

[OT] Benefit and belief [was Re: Suggested coding style]

DevPlayer wrote: > On Sep 27, 10:25 pm, alex23 wrote: >> And like the Bible, the Zen was created by humans as a joke. If you're >> taking it too seriously, that's your problem. [...] > Calling the Bible a joke is used to hurt people, not enlighten them. > Those words show bitter arrogance, not co

Re: Suggested coding style

* DevPlayer [110928 04:31]: > On Sep 27, 10:25 pm, alex23 wrote: > > rantingrick wrote: > > > Since, like the bible > > > the zen is self contradicting, any argument utilizing the zen can be > > > defeated utilizing the zen. > > > > And like the Bible, the Zen was created by humans as a joke. If

Re: Suggested coding style

DevPlayer writes: > Calling the Bible a joke is used to hurt people, not enlighten them. How do you know that? > Those words show bitter arrogance, not constructive critism How do you know that? > as it ignores how others feel about that book. That strikes me as a good thing; how people feel

Re: Suggested coding style

On Sep 27, 10:25 pm, alex23 wrote: > rantingrick wrote: > > Since, like the bible > > the zen is self contradicting, any argument utilizing the zen can be > > defeated utilizing the zen. > > And like the Bible, the Zen was created by humans as a joke. If you're > taking it too seriously, that's y

Re: Suggested coding style

rantingrick wrote: > Since, like the bible > the zen is self contradicting, any argument utilizing the zen can be > defeated utilizing the zen. And like the Bible, the Zen was created by humans as a joke. If you're taking it too seriously, that's your problem. > If however you want to learn abou

  1   2   3   4   >