On 4 June 2013 14:35, Mark Lawrence wrote:
> On 04/06/2013 14:29, rusi wrote:
>> The Clash of the Titans
>>
>> Lé jmf chârgeth with mightƴ might
>> And le Mond underneath trembleth
>> Now RR mounts his sturdy steed
>> And the windmill yonder turneth
>>
>
> +1 funniest poem of the week :)
Week? Do
On 6/6/13, alex23 wrote:
> On Jun 7, 11:44 am, Mark Janssen wrote:
>> > Bulshytt. If you have no idea what polymorphism is, you shouldn't even
>> > be participating in this conversation.
>>
>> I am aware of what it means, but Python doesn't really have it
>
> You really need to stop commenting wh
On Jun 7, 8:24 am, rusi wrote:
> On Jun 7, 8:14 am, Mark Janssen wrote:
>
>
>
>
>
>
>
>
>
> > >> I am aware of what it means, but Python doesn't really have it (although
> > >> it may evolve to it with annotations).
>
> > > No polymorphism huh?
>
> > > py> len([1, 2, 3]) # len works on lists
> >
> Fairly definitive terms have existed since 1985:
> http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
>>
>> You are making an "outside view of a function" (until a better term is
>> found). So that give you one possible view of polymorphism. However,
>> *within* a class that I would write,
On Jun 7, 8:14 am, Mark Janssen wrote:
> >> I am aware of what it means, but Python doesn't really have it (although
> >> it may evolve to it with annotations).
>
> > No polymorphism huh?
>
> > py> len([1, 2, 3]) # len works on lists
> > 3
> > py> len((1, 2)) # and on tuples
> > 2
> > py> len({}
>> I am aware of what it means, but Python doesn't really have it (although
>> it may evolve to it with annotations).
>
> No polymorphism huh?
>
>
> py> len([1, 2, 3]) # len works on lists
> 3
> py> len((1, 2)) # and on tuples
> 2
> py> len({}) # and on dicts
> 0
> py> len('I pity the fool') #
On Jun 6, 11:44 pm, Devin Jeanpierre wrote:
>
> > Unfortunately* the halting problem stands. When generalized to Rice
> > theorem it says that only trivial properties of programs are
> > algorithmically decidable:
> >http://mathworld.wolfram.com/RicesTheorem.html
>
> > And so the semantic correct
On Thu, 06 Jun 2013 18:44:49 -0700, Mark Janssen wrote:
>>> Python has seduced us all into lazy typing. That's what it is.
>>
>> Bulshytt. If you have no idea what polymorphism is, you shouldn't even
>> be participating in this conversation.
>
> I am aware of what it means, but Python doesn't re
On Jun 7, 11:44 am, Mark Janssen wrote:
> > Bulshytt. If you have no idea what polymorphism is, you shouldn't even
> > be participating in this conversation.
>
> I am aware of what it means, but Python doesn't really have it
You really need to stop commenting when you clearly have no
understandin
>> Python has seduced us all into lazy typing. That's what it is.
>
> Bulshytt. If you have no idea what polymorphism is, you shouldn't even
> be participating in this conversation.
I am aware of what it means, but Python doesn't really have it
(although it may evolve to it with annotations). Bu
On Thu, Jun 6, 2013 at 9:49 AM, Rick Johnson
wrote:
> Congrats: Again you join the ranks of most children who make excuses for
> their foolish actions along the lines of:
>
> "Hey, they did it first!"
>
> Well, the lemmings get what they deserve i suppose.
>
Lemmings don't really jump off cliffs
On Jun 7, 2:39 am, Devin Jeanpierre wrote:
> Languages do not exist in a vacuum.
They do if all you use them for is academic point scoring over
practical purposes.
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 7, 3:59 am, Mark Janssen wrote:
> Okay, I'm going straighten out you foo(l)s once and for all.
Gosh, really?! THANKS.
> Python has seduced us all into lazy typing. That's what it is.
Bulshytt. If you have no idea what polymorphism is, you shouldn't even
be participating in this conversa
Super OT divergence because I am a loser nerd:
On Thu, Jun 6, 2013 at 1:27 PM, rusi wrote:
> Yes, all programming communities have blind-spots. The Haskell
> community's is that Haskell is safe and safe means that errors are
> caught at compile-time.
I don't think Haskell people believe this wi
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
On Thursday, June 6, 2013 2:29:02 AM UTC-7, Steven D'Aprano wrote:
> On Thu, 06 Jun 2013 12:29:44 +1000, Chris Angelico wrote:
>
>
>
> > On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
>
> > wrote:
>
> >> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
>
> >>> As for Python, my experienc
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,
> Whatever benefit there is in declaring the type of a function is lost due
> to the inability to duck-type or program to an interface. There's no type
> that says "any object with a 'next' method", for example. And having to
> declare local variables is a PITA with little benefit.
>
> Give me a la
On 2013-06-06, Chris Angelico wrote:
> Would you say that doubling the testing period is a good thing or a
> bad thing?
It could be a neutral thing (ignoring the costs involved).
I once read read an article claiming that as you test (and fix) any
large, complex piece of software, you asymptotic
On Jun 6, 9:08 pm, Robert Kern wrote:
> On 2013-06-06 16:41, Chris Angelico wrote:
>
> > Anyway, regardless of your language, there's always some criteria that
> > can't be coded. Suppose the valid input for a function were "integers
> > whose square roots are integers but whose cube roots are not
On Fri, Jun 7, 2013 at 2:49 AM, Rick Johnson
wrote:
> On Wednesday, June 5, 2013 2:15:57 AM UTC-5, Chris Angelico wrote:
>> [...]
>> I cannot name a single modern programming language that does NOT have
>> some kind of implicit boolification.
>
> Congrats: Again you join the ranks of most children
On Wednesday, June 5, 2013 2:15:57 AM UTC-5, Chris Angelico wrote:
> [...]
> I cannot name a single modern programming language that does NOT have
> some kind of implicit boolification.
Congrats: Again you join the ranks of most children who make excuses for their
foolish actions along the lines
On Thu, Jun 6, 2013 at 12:24 PM, Rick Johnson
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 traditi
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 n
On 2013-06-06 16:41, Chris Angelico wrote:
Anyway, regardless of your language, there's always some criteria that
can't be coded. Suppose the valid input for a function were "integers
whose square roots are integers but whose cube roots are not". You
won't easily get compile-time checking of tha
On Fri, Jun 7, 2013 at 1:49 AM, Rick Johnson
wrote:
> On Wednesday, June 5, 2013 11:59:07 AM UTC-5, Chris Angelico wrote:
>
>> Frankly, I don't think the language much matters. It's all
>> down to the skill of the programmers and testers. Ada
>> wasn't the source of the problem unless Ada has a bu
On Wednesday, June 5, 2013 11:59:07 AM UTC-5, Chris Angelico wrote:
> Frankly, I don't think the language much matters. It's all
> down to the skill of the programmers and testers. Ada
> wasn't the source of the problem unless Ada has a bug in
> it... which is going to be true of pretty much any
>
On Fri, Jun 7, 2013 at 1:35 AM, Robert Kern wrote:
> On 2013-06-06 10:45, Chris Angelico wrote:
>
>> For the "accept any object that has a next() method" sorts of rules, I
>> don't know of any really viable system that does that usefully. The
>> concept of implementing interfaces in Java comes clo
On Fri, Jun 7, 2013 at 1:36 AM, rusi wrote:
> On Jun 6, 8:26 pm, Chris Angelico wrote:
>> On Fri, Jun 7, 2013 at 12:09 AM, rusi 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 segf
On Jun 6, 8:26 pm, Chris Angelico wrote:
> On Fri, Jun 7, 2013 at 12:09 AM, rusi 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(
On 2013-06-06 10:45, Chris Angelico wrote:
For the "accept any object that has a next() method" sorts of rules, I
don't know of any really viable system that does that usefully. The
concept of implementing interfaces in Java comes close, but the class
author has to declare that it's implementing
On Fri, Jun 7, 2013 at 12:09 AM, rusi 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(9)
def foo(): foo()
foo()
:)
ChrisA
--
http:
On Jun 6, 6:45 am, Chris Angelico wrote:
> On Thu, Jun 6, 2013 at 11:37 AM, Steven D'Aprano
>
> wrote:
> > What prevents bugs is the skill of the people writing the code, not the
> > compiler.
>
> +1 QOTW.
In many Indian languages there is a saying: A poor dancer blames the
crooked floor. [Yeah…
06.06.13 12:45, Chris Angelico написав(ла):
For the "accept any object that has a next() method" sorts of rules, I
don't know of any really viable system that does that usefully. The
concept of implementing interfaces in Java comes close, but the class
author has to declare that it's implementing
On Thu, Jun 6, 2013 at 7:29 PM, Steven D'Aprano
wrote:
> Whatever benefit there is in declaring the type of a function is lost due
> to the inability to duck-type or program to an interface. There's no type
> that says "any object with a 'next' method", for example. And having to
> declare local v
On Thu, 06 Jun 2013 12:29:44 +1000, Chris Angelico wrote:
> On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
> wrote:
>> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
>>> As for Python, my experience with it is that, as your application
>>> grows, you start getting confused about what the ar
On Wed, Jun 5, 2013 at 10:25 PM, Russ P. wrote:
> I recall reading a few years ago that Guido was thinking about adding
> optional type annotations. I don't know if that went anywhere or not, but I
> thought it was a good idea. Eventually I got tired of waiting, and I realized
> that I just wan
On Wednesday, June 5, 2013 7:29:44 PM UTC-7, Chris Angelico wrote:
> On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
>
> wrote:
>
> > On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
>
> >> As for Python, my experience with it is that, as
>
> >> your application grows, you start getting con
On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
wrote:
> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
>> As for Python, my experience with it is that, as
>> your application grows, you start getting confused about what the
>> argument types are or are supposed to be.
>
> Whereas people neve
On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
> I'm not an Ada guy, but Ada advocates claim that it reduces development
> time by half in the long run compared to C and C++ due to reduced
> debugging time and simpler maintenance.
They may be right. Far too many people think that C and C++
On Thu, Jun 6, 2013 at 11:37 AM, Steven D'Aprano
wrote:
> What prevents bugs is the skill of the people writing the code, not the
> compiler.
+1 QOTW.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
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:
>>
>> > But then, what would you expect of a language that allows you to
>> > write
>> >
>> > x = 1
>> > x = "Hello"
>> >
>> > It's all loo
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
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 a
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
On Wednesday, June 5, 2013 9:59:07 AM UTC-7, Chris Angelico wrote:
> On Thu, Jun 6, 2013 at 2:15 AM, Russ P. wrote:
>
> > On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
>
> >> I want to launch this rocket with an expensive satellite on top. I know
>
> >>
>
> >> it's safe as
On Thu, Jun 6, 2013 at 2:15 AM, Russ P. wrote:
> On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
>> I want to launch this rocket with an expensive satellite on top. I know
>>
>> it's safe as the code is written in ADA. Whoops :(
>
>
> So Python would have been a better choice?
On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
> On 05/06/2013 07:11, 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 applicati
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 tha
On 05/06/2013 07:11, 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 want to launch this rocket with an expensive satellite on top.
On Wednesday, June 5, 2013 12:15:57 AM UTC-7, Chris Angelico wrote:
> On Wed, Jun 5, 2013 at 4:11 PM, Russ P. wrote:
>
> > On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
>
> >
>
> >> Yes, but the problem is not "my approach", rather the lack
>
> >>
>
> >> of proper language des
On Wed, Jun 5, 2013 at 4:11 PM, Russ P. wrote:
> On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
>
>> Yes, but the problem is not "my approach", rather the lack
>>
>> of proper language design (my apologizes to the "anointed
>>
>> one". ;-)
>
> If you don't like implicit conversion
On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
> Yes, but the problem is not "my approach", rather the lack
>
> of proper language design (my apologizes to the "anointed
>
> one". ;-)
If you don't like implicit conversion to Boolean, then maybe you should be
using another langu
On Jun 5, 3:28 pm, Steven D'Aprano wrote:
> How many years has Rick been coming here, proclaiming loudly [a]nd yet,
> he still has no clue what
> actually means.
It's not just duck typing.
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 05 Jun 2013 02:27:26 +1000, Chris Angelico wrote:
> On Wed, Jun 5, 2013 at 2:19 AM, Rick Johnson
> wrote:
>> On Jun 4, 11:00 am, Chris Angelico wrote:
>>> You know, if you want a language with strict type declarations and
>>> extreme run-time efficiency, there are some around.
>>
>> I do
On 06/04/2013 05:21 PM, Rick Johnson wrote:
> If you still feel that this idea is garbage, then, keep on writing
> your sloppy code. My proposal is the best method to handle the
> problems that arise with duck typed languages in a manner that is not
> restrictive or laborious -- it's actually quite
On Tue, 04 Jun 2013 05:23:19 -0700, jmfauth wrote:
> How is is possible to arrive to such a situation ? The answer if far
> beyond my understanding
Truer words have never been spoken.
> (although I have my opinion on the subject).
http://en.wikipedia.org/wiki/Dunning–Kruger_effect
--
Stev
On Jun 5, 2:09 am, Rick Johnson wrote:
> This is how you design a language for consistency and readability.
Great! Now you can shut up and get back to work on RickPython4000.
Come back and let us know all about it when it's done.
--
http://mail.python.org/mailman/listinfo/python-list
On 05/06/2013 00:21, Rick Johnson wrote:
[snip]
Would you be kind enough not to smoke too much wacky baccy before
posting, thanks.
--
"Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green." Snooker
commentator 'Whispering'
On Jun 4, 12:42 pm, Ian Kelly wrote:
> > By this manner, we can roll three common tests into one
> > method:
> > * Boolean conversion
> > * member truthiness for iterables
> > * type checking
> How exactly does this is_valid method perform the first two? Are you
> suggesting that an
On Tue, Jun 4, 2013 at 9:44 AM, Rick Johnson
wrote:
> It is my firm belief that truth testing a value that is not
> a Boolean should raise an exception. If you want to convert
> a type to Boolean then pass it to the bool function:
>
> lst = [1,2,3]
> if bool(lst):
> do_something
>
On Tue, Jun 4, 2013 at 11:44 AM, Rick Johnson
wrote:
>
> This implicit conversion seems like a good idea at first,
> and i was caught up in the hype myself for some time: "Hey,
> i can save a few keystrokes, AWESOME!". However, i can tell
> you with certainty that this implicit conversion is folly
On 6/4/2013 12:19 PM, Rick Johnson wrote:
On Jun 4, 11:00 am, Chris Angelico wrote:
You know, if you want a language with strict type declarations and
extreme run-time efficiency, there are some around.
I don't like declaring types everywhere, i hate it. I prefer duck
typed languages, HOWEVER
On Wed, Jun 5, 2013 at 2:19 AM, Rick Johnson
wrote:
> On Jun 4, 11:00 am, Chris Angelico wrote:
>> You know, if you want a language with strict type declarations and
>> extreme run-time efficiency, there are some around.
>
> I don't like declaring types everywhere, i hate it. I prefer duck
> type
On Jun 4, 11:00 am, Chris Angelico wrote:
> You know, if you want a language with strict type declarations and
> extreme run-time efficiency, there are some around.
I don't like declaring types everywhere, i hate it. I prefer duck
typed languages, HOWEVER, in order for duck typing to work
consist
On Jun 4, 10:44 am, Rick Johnson wrote:
> What we need is a method by which we can validate a symbol
> and simultaneously do the vaidation in a manner that will
> cast light on the type that is expected. In order for this
> to work, you would need validators with unique "type names"
>
> if va
On 4 Jun 2013 17:04, "Chris Angelico" wrote:
>
> On Wed, Jun 5, 2013 at 1:44 AM, Rick Johnson
> wrote:
> > But we are really ignoring the elephant in the room. Implict
> > conversion to Boolean is just a drop in the bucket compared
> > to the constant "shell game" we are subjected to when
> > rea
On Wed, Jun 5, 2013 at 1:44 AM, Rick Johnson
wrote:
> But we are really ignoring the elephant in the room. Implict
> conversion to Boolean is just a drop in the bucket compared
> to the constant "shell game" we are subjected to when
> reading source code. We so naively believe that a symbol
> name
On Tuesday, June 4, 2013 12:39:59 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 03 Jun 2013 18:37:24 -0700, Rick Johnson wrote:
> Consider a simple thought experiment. Suppose we start with a sequence of
> if statements that begin simple and get more complicated:
> if a == 1: ...
> if a == 1 and b >
On 04/06/2013 14:29, rusi wrote:
On Jun 4, 5:23 pm, jmfauth wrote:
On 2 juin, 20:09, Rick Johnson wrote:
I never purposely inject ANY superfluous cycles in my code except in
the case of testing or development. To me it's about professionalism.
Let's consider a thought exercise shall we?
On Jun 4, 5:23 pm, jmfauth wrote:
> On 2 juin, 20:09, Rick Johnson wrote:
>
>
>
> > I never purposely inject ANY superfluous cycles in my code except in
> > the case of testing or development. To me it's about professionalism.
> > Let's consider a thought exercise shall we?
>
>
>
> The f
On 2 juin, 20:09, Rick Johnson wrote:
> >
> >
>
> I never purposely inject ANY superfluous cycles in my code except in
> the case of testing or development. To me it's about professionalism.
> Let's consider a thought exercise shall we?
>
The flexible string representation is the per
On Tue, Jun 4, 2013 at 11:37 AM, Rick Johnson
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
On Mon, 03 Jun 2013 18:37:24 -0700, Rick Johnson wrote:
> On Sunday, June 2, 2013 1:58:30 PM UTC-5, Steven D'Aprano wrote:
>> On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:
>> > A "wise programmer" may think he's solved the problem by writing a
>> > function called "debugprint" that looks
On Tue, 04 Jun 2013 05:16:13 +0200, Vito De Tullio wrote:
> Rick Johnson wrote:
>
>> Take your
>> standard yes/no/cancel dialog, i would expect it to return
>> True|False|None respectively,
>
> you clearly mean True / False / FileNotFound.
>
> ( http://thedailywtf.com/Articles/What_Is_Truth_0x3
On Monday, June 3, 2013 10:16:13 PM UTC-5, Vito De Tullio wrote:
> Rick Johnson wrote:
> > Take your
> > standard yes/no/cancel dialog, i would expect it to return
> > True|False|None respectively,
> you clearly mean True / False / FileNotFound.
No, i clearly meant what i said :-). FileDialogs onl
Rick Johnson wrote:
> Take your
> standard yes/no/cancel dialog, i would expect it to return
> True|False|None respectively,
you clearly mean True / False / FileNotFound.
( http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )
--
ZeD
--
http://mail.python.org/mailman/listinfo/python-lis
On Sunday, June 2, 2013 1:58:30 PM UTC-5, Steven D'Aprano wrote:
> On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:
Oh Steven, you've really outdone yourself this time with the
theatrics. I hope you scored some "cool points" with your
minions. Heck, you almost had me convinced until i slapp
On Tue, Jun 4, 2013 at 6:31 AM, Steven D'Aprano
wrote:
> ... quite frankly I have no sympathy for
> the view that CPU cycles are so precious that we mustn't waste them. If
> that were the case, Python is the wrong language.
CPU cycles *are* valuable still, though. The efficiency of your code
dete
On Mon, 03 Jun 2013 15:09:48 -0400, Jason Swails wrote:
> But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
> ignore-rule to squash out all of these functions, I'm simply suggesting
> that sometimes it's worth commenting-out debug print calls instead of
> 'just leaving them th
ack, sorry for the double-post.
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly wrote:
> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails
> wrote:
> > 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 rece
On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly wrote:
> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails
> wrote:
> > 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 rece
On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails wrote:
> 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 an
On 06/03/2013 04:49 AM, Mark Lawrence wrote:
On 03/06/2013 04:10, Dan Sommers 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.
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-place
On 03/06/2013 04:10, Dan Sommers 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. ;-)
We used to run into those back in the da
On Mon, 03 Jun 2013 17:17:12 +1000, Chris Angelico wrote:
> On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie
> wrote:
>> On 06/02/2013 12:18 PM, Rick Johnson wrote:
>>> On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
>
On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie wrote:
> On 06/02/2013 12:18 PM, Rick Johnson wrote:
>> On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
>>> On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
>>> [...] Or use the
On Mon, Jun 3, 2013 at 12:34 AM, Dan Sommers 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 sa
On 06/02/2013 12:18 PM, Rick Johnson wrote:
> On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
>> On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
>>> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
>> [...] Or use the logging module. It's easy to get going quickly
>> (just cal
On Mon, Jun 3, 2013 at 2:34 PM, Dan Sommers 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
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 c
On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote:
> On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers
> 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
On 3 June 2013 13:23, Jason Swails 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 Fortra
On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers 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
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 m
On Mon, Jun 3, 2013 at 10:16 AM, Jason Swails wrote:
> 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=Fal
On Sun, Jun 2, 2013 at 1:20 PM, Chris Angelico 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=100)
> 0.5838018519113444
>
>
On 6/2/2013 2:18 PM, Rick Johnson wrote:
On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
[...]
Or use the logging module. It's easy to get going quickly
(just call logging.bas
1 - 100 of 110 matches
Mail list logo
