Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #46708 > unrolled thread
| Started by | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| First post | 2013-06-02 10:04 -0700 |
| Last post | 2013-06-03 15:11 -0400 |
| Articles | 20 on this page of 109 — 26 participants |
Back to article view | Back to comp.lang.python
PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 10:04 -0700
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 03:20 +1000
Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-02 17:49 +0000
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 11:18 -0700
Re: PyWart: The problem with "print" Ned Batchelder <ned@nedbatchelder.com> - 2013-06-02 16:45 -0400
Re: PyWart: The problem with "print" Michael Torrie <torriem@gmail.com> - 2013-06-02 23:49 -0600
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 17:17 +1000
Re: PyWart: The problem with "print" Alister <alister.ware@ntlworld.com> - 2013-06-03 08:01 +0000
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 11:09 -0700
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-02 19:03 +0000
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 06:21 +1000
Re: PyWart: The problem with "print" jmfauth <wxjmfauth@gmail.com> - 2013-06-04 05:23 -0700
Re: PyWart: The problem with "print" rusi <rustompmody@gmail.com> - 2013-06-04 06:29 -0700
Re: PyWart: The problem with "print" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-04 14:35 +0100
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-05 05:03 +0000
Re: PyWart: The problem with "print" Andrew Berg <robotsondrugs@gmail.com> - 2013-06-02 12:30 -0500
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 03:34 +1000
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-02 18:58 +0000
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 06:28 +1000
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-03 18:37 -0700
Re: PyWart: The problem with "print" Vito De Tullio <vito.detullio@gmail.com> - 2013-06-04 05:16 +0200
Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-03 20:53 -0700
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-04 04:30 +0000
Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-04 05:39 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 08:44 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 02:00 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 09:19 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 02:27 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-05 05:28 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-04 22:31 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ned Batchelder <ned@nedbatchelder.com> - 2013-06-04 13:25 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 09:09 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-04 18:31 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Fábio Santos <fabiosantosart@gmail.com> - 2013-06-04 17:10 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Jason Swails <jason.swails@gmail.com> - 2013-06-04 13:32 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-04 11:42 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 16:21 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-05 00:37 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-04 23:28 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-04 23:11 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 17:15 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 00:47 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 09:49 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 02:59 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Dan Stromberg <drsalists@gmail.com> - 2013-06-06 18:26 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-05 09:59 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 09:15 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 02:59 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 14:59 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 01:56 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 12:29 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 21:25 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-06 00:06 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 09:29 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 19:45 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Serhiy Storchaka <storchaka@gmail.com> - 2013-06-06 14:12 +0300
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Robert Kern <robert.kern@gmail.com> - 2013-06-06 16:35 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:41 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Robert Kern <robert.kern@gmail.com> - 2013-06-06 17:08 +0100
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 10:27 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-06 14:44 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 10:59 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 17:53 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 18:44 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 19:03 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 22:01 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-07 02:29 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 20:14 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 20:24 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 20:30 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 20:43 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-06 11:08 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 08:49 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 02:00 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Grant Edwards <invalid@invalid.invalid> - 2013-06-06 17:32 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 01:37 +0000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 11:45 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 07:09 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:26 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 08:36 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:46 +1000
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 11:03 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 11:11 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-05 12:10 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-05 17:18 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 16:52 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-05 19:20 -0600
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 09:24 -0700
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-06 12:39 -0400
Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 17:55 -0700
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-04 17:30 +1000
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-02 20:16 -0400
Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-03 03:10 +0000
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-02 23:23 -0400
Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-03 04:20 +0000
Re: PyWart: The problem with "print" Robert Kern <robert.kern@gmail.com> - 2013-06-03 11:52 +0100
Re: PyWart: The problem with "print" Tim Delaney <timothy.c.delaney@gmail.com> - 2013-06-03 13:37 +1000
Python Heisenbugs? (was: Re: PyWart: The problem with "print") Dan Sommers <dan@tombstonezero.net> - 2013-06-03 04:34 +0000
Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") Chris Angelico <rosuav@gmail.com> - 2013-06-03 15:05 +1000
Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-03 03:06 -0400
Re: PyWart: The problem with "print" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-03 09:49 +0100
Re: PyWart: The problem with "print" Dave Angel <davea@davea.name> - 2013-06-03 08:56 -0400
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 12:02 +1000
Re: PyWart: The problem with "print" Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-03 11:12 -0600
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:09 -0400
Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-03 20:31 +0000
Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-04 06:44 +1000
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:10 -0400
Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:11 -0400
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-07 01:46 +1000 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <mailman.2809.1370533600.3114.python-list@python.org> |
| In reply to | #47232 |
On Fri, Jun 7, 2013 at 1:36 AM, rusi <rustompmody@gmail.com> wrote: > On Jun 6, 8:26 pm, Chris Angelico <ros...@gmail.com> wrote: >> On Fri, Jun 7, 2013 at 12:09 AM, rusi <rustompm...@gmail.com> wrote: >> > When we switched from to python (via Scheme and a haskell- >> > predecessor), I dont remember ever getting a segmentation fault. >> >> Oh, it's easy to segfault Python. >> >> import sys >> sys.setrecursionlimit(999999999) >> def foo(): foo() >> foo() >> >> :) >> >> ChrisA > > And so you are hereby anointed into the august company of RR!! Eh? No, I'm just adept at breaking stuff... I could probably segfault a 100Mbit switch if I tried (or just got careless). ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2013-06-06 11:03 -0700 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <110c91d8-2447-4c5c-9e4d-f3b20ca16070@googlegroups.com> |
| In reply to | #47169 |
On Wednesday, June 5, 2013 8:37:20 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 05 Jun 2013 09:15:01 -0700, Russ P. wrote:
> > On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
> >> On 05/06/2013 07:11, Russ P. wrote:
> What prevents bugs is the skill of the people writing the code, not the
> compiler. Compile-time static type checking is merely a tool, which has
> costs and benefits. It is ludicrous to think that any one single tool, or
> the lack of that tool, will make all the difference between working code
> and non-working code.
Yes, just as ludicrous as thinking that dynamic languages have abolished the evil practice of "type checking".
> Static type-checking is no better, or worse, for "critical code" than
> dynamic type-checking. One language chooses to deal with some errors at
> compile-time, others deal with them at run-time.
Wow, talk about ignoring the elephant in the room! I don't feel i need static typed languages for EVERY problem, however, i'm not foolish enough to believe that "compile time type checking" and "run-time type checking" are even comparable. Oversimplification?
> Either way, the
> programmer has to deal with them in some way.
> A static type system forces you to deal with a limited subset of errors,
> "type errors", in one way only: by removing any execution paths in the
> software which would assign data of type X to a variable of type Y. For
> reasons of machine efficiency, that is often a good was to deal with such
> errors. But a dynamic type system makes different trade-offs.
> And of course, type errors are such a vanishingly small subset of all the
> possible errors that might be made that, frankly, the difference in code
> quality between those with static typing and those without is essentially
> indistinguishable. There's no evidence that code written in static typed
> languages is less buggy than code written in dynamic languages.
WOW! Your skill with the implicit Ad hominem is approaching guru status.
First you cleverly convert the base argument of this ongoing discussion from: "implicit conversion to boolean is bad", into the hot button topic of: "static vs dynamic typing".
In this manner you can ratchet up the emotion of your supporters by employing the same political "slight of hand" used by countless political hacks: "Liberal vs Republican" ring a bell? When there is only two choices, the sheeple can be easily manipulated by the football game. Especially when the opposing sides have the same end-goal in mind. It's all a game of diversions you idiots!
Then you go and make a blanket statement that "appears" to weigh the differences of the two styles fairly, when in fact, what you've done is to falsely invalidate the opposition's entire argument based on a complete overstatement (not to mention that you stopped short of explaining the "trade offs" in detail):
> And of course, type errors are such a vanishingly
> small subset of all the possible errors that might be
> made that, frankly, the difference in code quality
> between those with static typing and those without is
> essentially indistinguishable.
Nice!
Well, then. You've slayed the enemy. If type errors are as rare as you claim, then by golly these crazy people who use static languages are really just fools. I mean, how could they not be? If they were as intelligent as YOU then they would see the truth!
Your attempts at sleight of hand are rather amusing. The whole point of this "implicit conversion to Boolean" discussion hinges around the fact that dynamic languages are okay for small to medium problems ( or for prototyping larger problems). But they cannot be depended on for mission critical code. And mission critical does not only encompass manned flights to mars, it could be any code that places your reputation on the line.
I don't want Python to be a static typed language. Neither do i believe that duck typing is wrong for Python. HOWEVER, what i DO believe is that dynamic languages can be unreliable if we do not:
1. Choose to be "explicit enough"
I've explained this in detail Ad-nauseam.
2. Fail to type check where type checking is due.
The second covers type checking objects that enter into new namespaces. That would cover all functions/methods arguments (at a minimum).
We don't need to type check EVERY single object (but of course the programmer could IF he wanted to). If i declare a variable[1] that points to a list in a block of code, then i reference that variable[1] in the same block of code, i see no reason to type check that variable[1] first. That is overkill and that is why people are turned off by static languages.
However, if i declare the same variable[1] and then pass that variable[1] into a function, the function should do a type check on all the arguments to guarantee that these arguments are in fact what they should be. This is how you strike a balance between explicit and implicit. This is how you inject sanity into your code bases.
[1]: stop your whining already about "python does not have variables". The word variable has both a technical meaning (which is another example of transforming a word improperly) and a general meaning. When used in a Python context the word "variable" takes on it's general meaning. Feel free to consult a dictionary if your still confused.
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2013-06-06 11:11 -0700 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <ccfdd25a-4721-4ac6-8f58-757e944b0f16@googlegroups.com> |
| In reply to | #47250 |
On Thursday, June 6, 2013 1:03:24 PM UTC-5, Rick Johnson wrote: > The second covers type checking objects that enter into new > namespaces. That would cover all functions/methods arguments > (at a minimum). Yeah, before anyone starts complaining about this, i meant to say "scope". Now you can focus on the *real* argument instead of spending all your time pointing out minutiae.
[toc] | [prev] | [next] | [standalone]
| From | Terry Jan Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-06-05 12:10 -0400 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <mailman.2739.1370448641.3114.python-list@python.org> |
| In reply to | #47026 |
On 6/5/2013 2:11 AM, Russ P. wrote: > But then, what would you expect of a language that allows you to > write > > x = 1 > x = "Hello" > > It's all loosey goosey -- which is fine for many applications but > certainly not for critical ones. I believe Shedskin, a Python *subset* compiler*, will reject that, because it compiles ints to C ints. Some code checkers might too.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-05 17:18 -0600 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <mailman.2769.1370474311.3114.python-list@python.org> |
| In reply to | #47026 |
On 06/05/2013 12:11 AM, Russ P. wrote: > But then, what would you expect of a language that allows you to > write > > x = 1 > x = "Hello" > > It's all loosey goosey -- which is fine for many applications but > certainly not for critical ones. This comment shows me that you don't understand the difference between names, objects, and variables. May sound like a minor quibble, but there're actually major differences between binding names to objects (which is what python does) and variables (which is what languages like C have). It's very clear Rick does not have an understanding of this either.
[toc] | [prev] | [next] | [standalone]
| From | "Russ P." <Russ.Paielli@gmail.com> |
|---|---|
| Date | 2013-06-05 16:52 -0700 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <a0efc8b8-2084-40df-b5b0-5f1878782d17@googlegroups.com> |
| In reply to | #47158 |
On Wednesday, June 5, 2013 4:18:13 PM UTC-7, Michael Torrie wrote: > On 06/05/2013 12:11 AM, Russ P. wrote: > > > But then, what would you expect of a language that allows you to > > > write > > > > > > x = 1 > > > x = "Hello" > > > > > > It's all loosey goosey -- which is fine for many applications but > > > certainly not for critical ones. > > > > This comment shows me that you don't understand the difference between > > names, objects, and variables. May sound like a minor quibble, but > > there're actually major differences between binding names to objects > > (which is what python does) and variables (which is what languages like > > C have). It's very clear Rick does not have an understanding of this > > either. My comment shows you nothing about what I understand about names, objects, and variables. You have chosen to question my understanding apparently because my point bothered you but you don't have a good reply. Then you link me with Rick for good measure. That's two ad hominems in three sentences.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-05 19:20 -0600 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <mailman.2775.1370481668.3114.python-list@python.org> |
| In reply to | #47163 |
On 06/05/2013 05:52 PM, Russ P. wrote: > My comment shows you nothing about what I understand about names, > objects, and variables. Yes that probably is true. > You have chosen to question my understanding apparently because my > point bothered you but you don't have a good reply. Then you link me > with Rick for good measure. That's two ad hominems in three > sentences. Your statement didn't bother me. I just felt, perhaps erroneously, that such a comment needs clarification. We get into trouble in python when we get caught up in treating python names exactly like variables and blame it on the lack of static typing. In uni we looked at various means of dealing with the name covering/hiding issue including renaming or requiring that each binding be a unique name (meaning the second x = "hello word" statement would be a runtime error). Anyway, I got a bit distracted by your example of using the same name twice with different objects when the real issue that can cause pain is function call parameter expectation. My apologies for linking you to Rick. You're right that was an ad-hominem attack, though I didn't intend that!
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2013-06-06 09:24 -0700 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <a4e1e453-6dd9-4fa0-8b3d-daa5226ffd98@googlegroups.com> |
| In reply to | #47158 |
On Wednesday, June 5, 2013 6:18:13 PM UTC-5, Michael Torrie wrote:
> On 06/05/2013 12:11 AM, Russ P. wrote:
> > But then, what would you expect of a language that allows you to
> > write
> > x = 1
> > x = "Hello"
> > It's all loosey goosey -- which is fine for many applications but
> > certainly not for critical ones.
> This comment shows me that you don't understand the difference between
> names, objects, and variables. May sound like a minor quibble, but
> there're actually major differences between binding names to objects
> (which is what python does) and variables (which is what languages like
> C have). It's very clear Rick does not have an understanding of this
> either.
Just because someone does not "prefer" this or that aspect of Python, does not mean they don't understand it. I understand "implicit conversion to Boolean" just fine, however, i don't like it. Actually, i hate it! I think it's foolish. It was invented by people who rather save a few keystrokes at the cost writing cryptic code. There are many good reasons for saving keystrokes, implicit conversion to Boolean is NOT one of them.
I make the same argument for "return". Some languages allow implicit return values from functions/methods. When writing a function with Ruby, the return statement is optional:
## START RUBY CODE ##
def foo:
"implicit return"
end
rb> puts foo
"implicit return"
## END RUBY CODE ##
This is one area where Python shines!
In Python, if you fail to use the return statement, then Python will return None, NOT some some value that just happens to be the last line executed in the function -- Ruby breaks the law of least astonishment.
The point is we must balance our selfish need to save keystrokes against the need of a reader to QUICKLY understand what he is reading. Python's "explicit return statement" satisfies both requirements, whereas, the optional return value of Ruby does not. We don't want to overly implicit, or overly explicit (as in the nightmare of "public static void foo", which is overkill (at least for a language as high level as Python)).
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2013-06-06 12:39 -0400 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <mailman.2815.1370536848.3114.python-list@python.org> |
| In reply to | #47241 |
On Thu, Jun 6, 2013 at 12:24 PM, Rick Johnson <rantingrickjohnson@gmail.com> wrote: > In Python, if you fail to use the return statement, then Python will return None, NOT some some value that just happens to be the last line executed in the function -- Ruby breaks the law of least astonishment. Ruby comes from a tradition where this behavior is not astonishing. Languages do not exist in a vacuum. -- Devin
[toc] | [prev] | [next] | [standalone]
| From | alex23 <wuwei23@gmail.com> |
|---|---|
| Date | 2013-06-06 17:55 -0700 |
| Subject | Re: Bools and explicitness [was Re: PyWart: The problem with "print"] |
| Message-ID | <9c3cf384-e627-4f52-96a7-2cf4f85c4bb6@qz2g2000pbb.googlegroups.com> |
| In reply to | #47242 |
On Jun 7, 2:39 am, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: > Languages do not exist in a vacuum. They do if all you use them for is academic point scoring over practical purposes.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-04 17:30 +1000 |
| Message-ID | <mailman.2624.1370331030.3114.python-list@python.org> |
| In reply to | #46827 |
On Tue, Jun 4, 2013 at 11:37 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> The print function is the very definition of a "syntactic sugar".
>
> For example:
> print("some sting")
>
> is much more readable than:
>
> sys.stdout.write("some string"+"\n")
> ...
> Again, the removal of a print function (or print statement)
> will not prevent users from calling the write method on
> sys.stdout or sys.stderr (or ANY "stream object" for that matter!)
And you could abolish ALL of the builtins by requiring that you import
ctypes and implement them all yourself. That is not the point of the
term. If print() is mere syntactic sugar, then everything is syntactic
sugar for Brainf* code.
The point of syntactic sugar is that there is a trivially-equivalent
underlying interpretation. For instance, in C, array subscripting is
trivially equivalent to addition and dereferencing:
a[i] <-> *(a+i)
This is syntactic sugar. The Python print() function does much more
than write(), so it is NOT syntactic sugar.
> Many times you'll get a result (or an input) that you expect
> to be a Boolean, but instead is a string. A good example of
> poor coding is "dialog box return values". Take your
> standard yes/no/cancel dialog, i would expect it to return
> True|False|None respectively, HOWEVER, some *idiot* decided
> to return the strings 'yes'|'no'|'cancel'.
Why True|False|None? Why should they represent Yes|No|Cancel?
Especially, *why None*? What has None to do with Cancel?
> However, with Python's implicit conversion to Boolean, the
> same conditional will ALWAYS be True: because any string
> that is not the null string is True (as far as Python is
> concerned). This is an example of Python devs breaking TWO
> Zens at once:
>
> "explicit is better than implicit"
> "errors should NEVER pass silently"
Right, because it's Python's fault that you can't use implicit boolean
conversion to sanely test for something that has three possible
outcomes. I think there's something in the nature of a boolean test
that makes this awkward, but I can't quite see it... hmm, some kind of
integer issue, I think...
> Obviously you don't appreciate the value of "explicit enough".
>
> if VALUE:
>
> is not explicit enough, however
>
> if bool(VALUE)
>
> or at least:
>
> if VALUE == True
>
> is "explicit enough".
Why? The 'if' implies a boolean context. In C, it's common to compare
integers for nonzeroness with a bare if; it's also common, though far
from universal, to compare strings for nullness - effectively
equivalent to "is not None". You don't need to be any more explicit
than that.
Granted, the definitions of truthiness differ from language to
language. In C, a NULL pointer is false and any actual pointer is
true, so an empty string is true (to the extent that C even has the
concept of strings, but leave that aside). In Pike, any array is true,
but the absence of an array can be indicated with (effectively) a
null, whereas Python deems that an empty list is false. Still, most
languages do have some system of coercion-to-boolean. (Notable
exception: REXX. An IF statement will accept *only* the two permitted
boolean values, anything else is an error.)
> However, if i choose to be explicit and use:
>
> "if len(VALUE) > 0:
>
> then the code will fail when it should: at the comparison
> line. Because any object that does not provide a __len__
> method would cause Python to raise NameError.
I thought you were dead against wasting CPU cycles! Your code here has
to calculate the actual length of the object, then compare it with
zero; the simple boolean check merely has to announce the presence or
absence of content. This is a HUGE difference in performance, and you
should totally optimize this down for the sake of that. Don't bother
measuring it, this will make more difference to your code than
replacing bubble sort with bogosort!
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jason Swails <jason.swails@gmail.com> |
|---|---|
| Date | 2013-06-02 20:16 -0400 |
| Message-ID | <mailman.2568.1370218591.3114.python-list@python.org> |
| In reply to | #46708 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Jun 2, 2013 at 1:20 PM, Chris Angelico <rosuav@gmail.com> wrote:
>
> Hmm. Could be costly. Hey, you know, Python has something for testing that.
>
> >>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
> DEBUG: return\n\tprint(*args)\nDEBUG=False',number=1000000)
> 0.5838018519113444
>
> That's roughly half a second for a million calls to debugprint().
> That's a 580ns cost per call. Rather than fiddle with the language,
> I'd rather just take this cost. Oh, and there's another way, too: If
> you make the DEBUG flag have effect only on startup, you could write
> your module thus:
>
This is a slightly contrived demonstration... The time lost in a function
call is not just the time it takes to execute that function. If it
consistently increases the frequency of cache misses then the cost is much
greater -- possibly by orders of magnitude if the application is truly
bound by the bandwidth of the memory bus and the CPU pipeline is almost
always saturated.
I'm actually with RR in terms of eliminating the overhead involved with
'dead' function calls, since there are instances when optimizing in Python
is desirable. I actually recently adjusted one of my own scripts to
eliminate branching and improve data layout to achieve a 1000-fold
improvement in efficiency (~45 minutes to 0.42 s. for one example) --- all
in pure Python. The first approach was unacceptable, the second is fine.
For comparison, if I add a 'deactivated' debugprint call into the inner
loop (executed 243K times in this particular test), then the time of the
double-loop step that I optimized takes 0.73 seconds (nearly doubling the
duration of the whole step). The whole program is too large to post here,
but the relevant code portion is shown below:
i = 0
begin = time.time()
for mol in owner:
for atm in mol:
blankfunc("Print i %d" % i)
new_atoms[i] = self.atom_list[atm]
i += 1
self.atom_list = new_atoms
print "Done in %f seconds." % (time.time() - begin)
from another module:
DEBUG = False
[snip]
def blankfunc(instring):
if DEBUG:
print instring
Also, you're often not passing a constant literal to the debug print --
you're doing some type of string formatting or substitution if you're
really inspecting the value of a particular variable, and this also takes
time. In the test I gave the timings for above, I passed a string the
counter substituted to the 'dead' debug function. Copy-and-pasting your
timeit experiment on my machine yields different timings (Python 2.7):
>>> import sys
>>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
DEBUG: return\n\tsys.stdout.write(*args)\nDEBUG=False',number=1000000)
0.15644001960754395
which is ~150 ns/function call, versus ~1300 ns/function call. And there
may be even more extreme examples, this is just one I was able to cook up
quickly.
This is, I'm sad to say, where my alignment with RR ends. While I use
prints in debugging all the time, it can also become a 'crutch', just like
reliance on valgrind or gdb. If you don't believe me, you've never hit a
bug that 'magically' disappears when you add a debugging print statement
;-).
The easiest way to eliminate these 'dead' calls is to simply comment-out
the print call, but I would be quite upset if the interpreter tried to
outsmart me and do it automagically as RR seems to be suggesting. And if
you're actually debugging, then you typically only add a few targeted print
statements -- not too hard to comment-out. If it is, and you're really
that lazy, then by all means add a new, greppable function call and use a
sed command to comment those lines out for you.
BTW: *you* in the above message refers to a generic person -- none of my
comments were aimed at anybody in particular
All the best,
Jason
P.S. All that said, I would agree with ChrisA's suggestion that the
overhead is negligible is most cases...
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2013-06-03 03:10 +0000 |
| Message-ID | <OOTqt.3497$3v4.600@newsfe23.iad> |
| In reply to | #46741 |
On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote: > ... If you don't believe me, you've never hit a bug that 'magically' > disappears when you add a debugging print statement ;-). Ah, yes. The Heisenbug. ;-) We used to run into those back in the days of C and assembly language. They're much harder to see in the wild with Python.
[toc] | [prev] | [next] | [standalone]
| From | Jason Swails <jason.swails@gmail.com> |
|---|---|
| Date | 2013-06-02 23:23 -0400 |
| Message-ID | <mailman.2576.1370229823.3114.python-list@python.org> |
| In reply to | #46756 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers <dan@tombstonezero.net> wrote: > On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote: > > > ... If you don't believe me, you've never hit a bug that 'magically' > > disappears when you add a debugging print statement ;-). > > Ah, yes. The Heisenbug. ;-) > Indeed. Being in the field of computational chemistry/physics, I was almost happy to have found one just to say I was hunting a Heisenbug. It seems to be a term geared more toward the physics-oriented programming crowd. > We used to run into those back in the days of C and assembly langua > > ge. > > They're much harder to see in the wild with Python. > > Yea, I've only run into Heisenbugs with Fortran or C/C++. Every time I've seen one it's been due to an uninitialized variable somewhere -- something valgrind is quite good at pinpointing. (And yes, a good portion of our code is -still- in Fortran -- but at least it's F90+ :).
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2013-06-03 04:20 +0000 |
| Message-ID | <GQUqt.42419$kF.3077@newsfe30.iad> |
| In reply to | #46758 |
On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote: > On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers <dan@tombstonezero.net> > wrote: >> Ah, yes. The Heisenbug. ;-) > > Indeed. Being in the field of computational chemistry/physics, I was > almost happy to have found one just to say I was hunting a Heisenbug. > It seems to be a term geared more toward the physics-oriented > programming crowd. I'd been using the word Heisenbug for years with only a pop-culture clue as to what it meant. Many years later, I went to college, studied physics (and math), and had one self-study semester of computational physics on my way to my undergraduate degree. After a career in software development, including a few years in the financial industry, with lots of floating point economic models, I must say that it was very enlightening. >> They're much harder to see in the wild with Python. > > Yea, I've only run into Heisenbugs with Fortran or C/C++. Every time > I've seen one it's been due to an uninitialized variable somewhere -- > something valgrind is quite good at pinpointing ... Uninitialized variables and off-by-one pointer operations. Little can screw up a calculation like mistaking a stack frame link for a floating point number. :-) > ... (And yes, a good portion of our code is -still- in Fortran -- but > at least it's F90+ :). I am a huge proponent of using the right tool for the job. There is nothing wrong with some well-placed FORTRAN, as long as the PSF
[toc] | [prev] | [next] | [standalone]
| From | Robert Kern <robert.kern@gmail.com> |
|---|---|
| Date | 2013-06-03 11:52 +0100 |
| Message-ID | <mailman.2590.1370256748.3114.python-list@python.org> |
| In reply to | #46760 |
On 2013-06-03 05:20, Dan Sommers wrote: > On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote: >> ... (And yes, a good portion of our code is -still- in Fortran -- but >> at least it's F90+ :). > > I am a huge proponent of using the right tool for the job. There is > nothing wrong with some well-placed FORTRAN, as long as the PSF No, no. It's the PSU that you have to worrNO CARRIER
[toc] | [prev] | [next] | [standalone]
| From | Tim Delaney <timothy.c.delaney@gmail.com> |
|---|---|
| Date | 2013-06-03 13:37 +1000 |
| Message-ID | <mailman.2577.1370230651.3114.python-list@python.org> |
| In reply to | #46756 |
[Multipart message — attachments visible in raw view] — view raw
On 3 June 2013 13:23, Jason Swails <jason.swails@gmail.com> wrote: > Yea, I've only run into Heisenbugs with Fortran or C/C++. Every time I've > seen one it's been due to an uninitialized variable somewhere -- something > valgrind is quite good at pinpointing. (And yes, a good portion of our > code is -still- in Fortran -- but at least it's F90+ :). > With the increase in use of higher-level languages, these days Heisenbugs most often appear with multithreaded code that doesn't properly protect critical sections, but as you say, with lower-level languages uninitialised memory is a common source of them. I had a fun one once (in C++, but could have happened in any language) where a semaphore was being acquired twice on the one thread. There were 10 semaphore slots available, and very occasionally the timings would result in one of the threads deadlocking. Fortunately, by reducing to a single thread + single semaphore slot I was able to turn it from a Heisenbug to a 100% replicable bug. Tim Delaney
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2013-06-03 04:34 +0000 |
| Subject | Python Heisenbugs? (was: Re: PyWart: The problem with "print") |
| Message-ID | <v1Vqt.25664$u_4.107@newsfe09.iad> |
| In reply to | #46759 |
On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote: > With the increase in use of higher-level languages, these days > Heisenbugs most often appear with multithreaded code that doesn't > properly protect critical sections, but as you say, with lower-level > languages uninitialised memory is a common source of them. Aside from an I/O caching bug directly affected by calling print or somefile.write (where somefile is stdout), how else could I create a Heisenbug in pure Python? To bring this thread back around full circle: I suppose that if I had a local function called print, and decided that I needed some debugging output, I could be in for a surprise; or a local module called logging, and decided to use the logging module instead of calling print directly.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-03 15:05 +1000 |
| Subject | Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") |
| Message-ID | <mailman.2579.1370235962.3114.python-list@python.org> |
| In reply to | #46761 |
On Mon, Jun 3, 2013 at 2:34 PM, Dan Sommers <dan@tombstonezero.net> wrote: > On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote: > >> With the increase in use of higher-level languages, these days >> Heisenbugs most often appear with multithreaded code that doesn't >> properly protect critical sections, but as you say, with lower-level >> languages uninitialised memory is a common source of them. > > Aside from an I/O caching bug directly affected by calling print or > somefile.write (where somefile is stdout), how else could I create a > Heisenbug in pure Python? If you have a @property, merely retrieving it could affect things. It shouldn't happen, but bugs can be anywhere. Basically, ANY Python code can trigger ANY Python code. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2013-06-03 03:06 -0400 |
| Subject | Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") |
| Message-ID | <mailman.2583.1370243205.3114.python-list@python.org> |
| In reply to | #46761 |
On Mon, Jun 3, 2013 at 12:34 AM, Dan Sommers <dan@tombstonezero.net> wrote: > On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote: > >> With the increase in use of higher-level languages, these days >> Heisenbugs most often appear with multithreaded code that doesn't >> properly protect critical sections, but as you say, with lower-level >> languages uninitialised memory is a common source of them. > > Aside from an I/O caching bug directly affected by calling print or > somefile.write (where somefile is stdout), how else could I create a > Heisenbug in pure Python? The garbage collector can do this, but I think in practice it's ridiculously rare, since __del__ is almost never useful due to its unreliability*. The problem is that the garbage collector can do whatever it wants. For example, in CPython it is called after so many cycles have been created. This allows code and user actions to inadvertently affect the garbage collector, and therefore, the invocation of __del__. If your __del__ does anything that accesses mutable global state also used elsewhere, it's conceivable that the order of someone else's access and __del__'s invocation depends on the GC. One order or the other might be the wrong one which causes a failure. As it happens, the "bt" command in pdb creates a cycle and might trigger the garbage collector, causing __del__ to run immediately, and potentially hiding the failure. This isn't really "pure python" in that Python doesn't even guarantee __del__ is ever called at all, let alone why. It's completely implementation-specific, and not a property of Python the language. -- Devin .. [*] Some people use it as an "unreliable fallback"; this turns their magical autosaving code into an attractive and yet horribly dangerous nuisance. Friends don't let friends use __del__.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web