[Tutor] Getting caller name without the help of "sys._getframe(1).f_code.co_name" ?

[Dave Angel]

patrice laporte wrote:
> 2010/2/14 Luke Paireepinart <rabidpoobear at gmail.com>
>
>   
>> I see why you would want the error messages but why is the default error
>> message not enough, that is why I am curious, and typically introspection on
>> objects is not necessary (for example, people often want to convert a string
>> into a variable name to store a value (say they have the string "foobar1"
>> and they want to store the value "f" in the variable "foobar1", how do they
>> change foobar1 to reference a string?  well you can just use exec but the
>> core issue is that there's really no reason to do it in the first place,
>> they can just use a dictionary and store dict['foobar1'] = 'f'  and it is
>> functionally equivalent (without the danger in the code)).  I get the
>> feeling that your issue is the same sort of thing, where an easier solution
>> exists but for whatever reason you don't see it.  I don't know if this is
>> true or not.  Here's my take on this:
>>
>>     
>>>>> class x(object):
>>>>>           
>>     def __init__(self, fname):
>>         self.temp = open(fname).read()
>>
>>
>>     
>>>>> a = x('foobar')
>>>>>           
>> Traceback (most recent call last):
>>   File "<pyshell#16>", line 1, in <module>               # this is the
>> module it's in
>>     a = x('foobar')                                                    #
>> this is the line where I tried to initialize it
>>   File "<pyshell#15>", line 3, in __init__                  # which called
>> this function, which is the one that has the error
>>     self.temp = open(fname).read()                          #and the error
>> occurred while trying to perform this operation
>> IOError: [Errno 2] No such file or directory: 'foobar'  #and the error was
>> that the file 'foobar' could not be found.
>>
>>
>>     
> Hi and thank to everybody...
>
> First of all, I consider my first question is now answered : I wanted to get
> rid of that sys._getframe call, I got an explanation (thanks to Kent).
>
> The rest of the discussion is not about Python, it's more about the way of
> thinking how to help the user having à good feeling with your app.
>
> I try to clarify my need and share you my anxiety. Of course, a lot of thing
> are available with Python, from a coder point of view. But what I want to do
> is to think about the user, and give him a way to understand that what he
> did was wrong.
>
> Traceback give me all I need, but my opinion is that it's not acceptable to
> give it back to the user without a minimum of "décorating". I didn't yet
> look at the logging module, and maybe it can help me to make that
> décorating.
>
> And the user must be a priority (it's still my conviction here)
>
> My own experience is that there is too much coder that forget the app they
> work on is aim to be used by "real human", not by C/C++/Python/put what ever
> you want here/ guru : if your app popups to the user a message that is just
> what the traceback gave, it's not a good thing : How can it be reasonable to
> imagine the user will read that kinda message ? :
>
> *Traceback (most recent call last):
>   File "<pyshell#16>", line 1, in <module>
>     a = x('foobar')
>   File "<pyshell#15>", line 3, in __init__
>     self.temp = open(fname).read()
> IOError: [Errno 2] No such file or directory: 'foobar'
> *
>
> Of course the origin of his problem is in the message : "*No such file or
> directory: 'foobar'*", but a customer will never read that @ù^$#é uggly
> message, there is too much extraterrestrial words in it.
>
> Traceback doesn' give more thant that, it doesn't say, as an example : we
> (the name of app) was trying to open the file "foobar" in order to do
> something with it (put here what it was supposed to do with the file) : app
> failed to open it because "foobar" doen't exist.
>
> According to me, traceback is what we need during "coding" phases, but it's
> not something to give to the user.
>
> This problem has to be solved by thinking the app in the way I'm trying to
> explain  (but not only in that way) : think about the user. This is not
> something I expect Python to do for me, I'm just looking for everything
> Python can provide me to make me think about the user.
>
> I'm new to Python, and I make a lot of exploration to understand and answer
> myself to my question. Python library is huge, and I don't have as enough
> time as I wanted to deal with it. But I'm conviced the solutions are here, I
> don't try to re-invent the wheel...
>
>
> Thant to you all.
>
>   
This makes lots of sense.  If the message doesn't make sense to the 
user, there's no point.  But why then is your thread titled "Getting 
caller name" ?  Why does the user care about the caller (function) 
name?  When you started the thread, it seemed clear that your user was a 
programmer, presumably who was adding code to your system and who wanted 
to see context error messages in coding terms.

If you have a duality of users, consider using a "DEBUG" variable, that 
changes the amount of detail you display upon an error.

DaveA