On Sat, Mar 16, 2013 at 2:27 PM, Rick Johnson
wrote:
>
> [snip junk]
> We don't need multiple layers of traces for NameErrors. Python does not
> have *real* global variables; and thank Guido for that! All we need to know
> is which module the error occurred in AND which line of that module
> conta
On Sat, Mar 16, 2013 at 8:14 PM, Steven D'Aprano
wrote:
> On Sat, 16 Mar 2013 19:58:41 -0600, Michael Torrie wrote:
>
>> On 03/16/2013 06:11 PM, Rick Johnson wrote:
>>> No, the "ACTUAL PROBLEM" is in the author.
>>
>> Surely any NameException can also be blamed on the author then, by your
>> logic
On Sun, Mar 17, 2013 at 2:14 PM, Steven D'Aprano
wrote:
> On Sat, 16 Mar 2013 19:58:41 -0600, Michael Torrie wrote:
>
>> On 03/16/2013 06:11 PM, Rick Johnson wrote:
>>> No, the "ACTUAL PROBLEM" is in the author.
>>
>> Surely any NameException can also be blamed on the author then, by your
>> logic
On Sat, 16 Mar 2013 19:58:41 -0600, Michael Torrie wrote:
> On 03/16/2013 06:11 PM, Rick Johnson wrote:
>> No, the "ACTUAL PROBLEM" is in the author.
>
> Surely any NameException can also be blamed on the author then, by your
> logic?
Any exception at all is obviously the author's fault. I propo
On 03/16/2013 06:11 PM, Rick Johnson wrote:
> No, the "ACTUAL PROBLEM" is in the author.
Surely any NameException can also be blamed on the author then, by your
logic?
--
http://mail.python.org/mailman/listinfo/python-list
On Saturday, March 16, 2013 6:48:01 PM UTC-5, Steven D'Aprano wrote:
> On Sat, 16 Mar 2013 21:19:34 +, Oscar Benjamin wrote:
> > [...]
> > NameErrors can occur conditionally depending on e.g. the
> > arguments to a function. Consider the following script:
> [...]
>
> Correct, although in your e
On Sun, Mar 17, 2013 at 10:50 AM, Rick Johnson
wrote:
> * Superfluous trackbacks are not only ugly, they damage
>productivity.
Extraordinary claims require extraordinary evidence. Start evidencing.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Mar 17, 2013 at 10:48 AM, Steven D'Aprano
wrote:
> Here's a truly trivial case where code will succeed or fail depending on
> the order of function calls.
> (chop code)
> It's not enough to know that the print line in display() fails, because
> that's merely the side-effect. The actual pro
On Saturday, March 16, 2013 6:29:52 PM UTC-5, Oscar Benjamin wrote:
> I wasn't looking to convince *you*, just to set the record
> straight that this behaviour is sometimes useful.
And you claim to "set the record strait" by posting code that *purposely*
raises a NameError when some function para
On Sat, 16 Mar 2013 21:19:34 +, Oscar Benjamin wrote:
> On 16 March 2013 18:27, Rick Johnson
> wrote:
>>
>> Sometimes many levels of trace messages can be helpful when detecting
>> bugs, however, in the case of NameErrors, these "nuggets" ejected from
>> deep within the bowls of the Python i
On Sun, Mar 17, 2013 at 10:36 AM, Tim Chase
wrote:
> Because, in the real world, that example looks something like
>
> def broken(intelligence_level):
> if intelligence_level < 100:
> return dumb_down(intellegence_level)
> else:
> return make_harder(intelligence_level)
> br
On 2013-03-16 15:39, Rick Johnson wrote:
> On Saturday, March 16, 2013 4:19:34 PM UTC-5, Oscar Benjamin wrote:
> > # tmp.py
> > def broken(x):
> > if x > 2:
> > print(x)
> > else:
> > print(undefined_name)
> >
> > broken(1)
>
> Why would anyone write code lik
On 16 March 2013 22:39, Rick Johnson wrote:
> On Saturday, March 16, 2013 4:19:34 PM UTC-5, Oscar Benjamin wrote:
>
>> The traceback shows the arguments passed to the broken
>> function that caused the NameError to be generated.
>> Different arguments would not have generated the
>> NameError. Thi
On Saturday, March 16, 2013 4:19:34 PM UTC-5, Oscar Benjamin wrote:
>
> NameErrors can occur conditionally depending on e.g. the
> arguments to a function. Consider the following script:
>
> # tmp.py
> def broken(x):
> if x > 2:
> print(x)
> else:
> print(undefi
On 16 March 2013 18:27, Rick Johnson wrote:
>
> Sometimes many levels of trace messages can be helpful when detecting bugs,
> however, in the case of NameErrors, these "nuggets" ejected from deep within
> the bowls of the Python interpreter are nothing more than steaming piles of
> incomprehen
Sometimes many levels of trace messages can be helpful when detecting bugs,
however, in the case of NameErrors, these "nuggets" ejected from deep within
the bowls of the Python interpreter are nothing more than steaming piles of
incomprehensible crap!
We don't need multiple layers of traces f
16 matches
Mail list logo
