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
15 matches
Mail list logo
