Python equivt of __FILE__ and __LINE__
Bill Davy
of an error. The "assembly language" is Python. If the user wants to
generat some object code they write something like:
Label(LoopLable)
Load(R4)
Dec()
JNZ(LoopLabel)
I can use Python to do all the expression evalutaion, conversion from Python
FP to target FP, include files, macros (done as function definitions). The
functions like Load() generate the approproyte object code.
So, for example, when a label is defined or referenced, I save the File,Line
so if there is not exactly one defintion or no references, I can report the
file location(s) to be considered. In the example, I would want to report
that LoopLable is not referenced, and LoopLabel is not defined.
TIA,
Bill
PS www.SynectixLtd.com is not relevant
Gary Herron
function called "extract_stack" which can give you a pointer to the
whole execution stack. From that can be generated all the usual stuff
you see in a traceback -- including file and line information. *How*
you extract that stuff, I'll leave as an exercises for the reader.
(Meaning I haven't a clue.)
Gary Herron
thebjorn
> Bill Davy wrote:
> > Writing a quick and dirty assembler and want to give the user the location
> > of an error. The "assembly language" is Python. If the user wants to
> > generat some object code they write something like:
>
> > Label(LoopLable)
> > Load(R4)
> > Dec()
> > JNZ(LoopLabel)
>
> > I can use Python to do all the expression evalutaion, conversion from Python
> > FP to target FP, include files, macros (done as function definitions). The
> > functions like Load() generate the approproyte object code.
>
> > So, for example, when a label is defined or referenced, I save the File,Line
> > so if there is not exactly one defintion or no references, I can report the
> > file location(s) to be considered. In the example, I would want to report
> > that LoopLable is not referenced, and LoopLabel is not defined.
>
> > TIA,
> > Bill
>
>
> You *can* get at that kind of information: The traceback module has a
> function called "extract_stack" which can give you a pointer to the
> whole execution stack. From that can be generated all the usual stuff
> you see in a traceback -- including file and line information. *How*
> you extract that stuff, I'll leave as an exercises for the reader.
> (Meaning I haven't a clue.)
>
> Gary Herron
I think the inspect module might be more useful... the getfile() and
getsourcelines() look promising.
-- bjorn
alain
def __LINE__():
try:
raise Exception
except:
return sys.exc_info()[2].tb_frame.f_back.f_lineno
def __FILE__():
return inspect.currentframe().f_code.co_filename
Best regards
Alain
Bill Davy
news:a9946b83-22f8-4da5...@i7g2000prf.googlegroups.com...
> On Feb 11, 4:55 pm, Gary Herron <gher...@islandtraining.com> wrote:
>> Bill Davy wrote:
>> > Writing a quick and dirty assembler and want to give the user the
>> > location
>> > of an error. The "assembly language" is Python. If the user wants to
>> > generat some object code they write something like:
>>
>> > Label(LoopLable)
>> > Load(R4)
>> > Dec()
>> > JNZ(LoopLabel)
>>
>> > I can use Python to do all the expression evalutaion, conversion from
>> > Python
>> > FP to target FP, include files, macros (done as function definitions).
>> > The
>> > functions like Load() generate the approproyte object code.
>>
>> > So, for example, when a label is defined or referenced, I save the
>> > File,Line
>> > so if there is not exactly one defintion or no references, I can report
>> > the
>> > file location(s) to be considered. In the example, I would want to
>> > report
>> > that LoopLable is not referenced, and LoopLabel is not defined.
>>
>> > TIA,
>> > Bill
>>
>> >
>>
>> function called "extract_stack" which can give you a pointer to the
>> whole execution stack. From that can be generated all the usual stuff
>> you see in a traceback -- including file and line information. *How*
>> you extract that stuff, I'll leave as an exercises for the reader.
>> (Meaning I haven't a clue.)
>>
>> Gary Herron
>
> I think the inspect module might be more useful... the getfile() and
> getsourcelines() look promising.
>
> -- bjorn
I think I'll go with the tarceback route because if the user defines
functions to emit code, I can traceback silently from where the error is
found to the call to Load() or Store() etc, and then trace back visibly, the
user will get a traceback of their code (and not my implementation details).
But very interesting and nice to know about these functions/modules. What a
lovely langauge.
Jeff Schwab
That's awesome. It's easy to see how these and other
'preprocessor-like' constructs could be wrapped into a convenient
module. But the leading and trailing double-underscores, and the
all-caps function names, seem very un-python. (It's not really going to
look like C, anyway, since the client code will need parentheses after
the pseudo-macro names.) What would be more pythonic? Maybe something
like this?
# srcinfo.py
import inspect
import sys
def line():
try:
raise Exception
except:
return sys.exc_info()[2].tb_frame.f_back.f_lineno
def file():
return inspect.currentframe().f_code.co_filename
if __name__ == '__main__':
print "%s: %d" % (file(), line())
# client.py
import srcinfo
if __name__ == '__main__':
try:
# Whatever.
raise Exception, "hello"
except Exception, x:
print ('warning: %s: %d: %s' %
(srcinfo.file(), srcinfo.line(), x))
Gabriel Genellina
escribi�:
> def line():
> try:
> raise Exception
> except:
> return sys.exc_info()[2].tb_frame.f_back.f_lineno
> def file():
> return inspect.currentframe().f_code.co_filename
It's not a good idea to shadow the file type; I'd suggest current_file and
current_line.
file() should return inspect.currentframe().f_back.f_code.co_filename,
else you're using the filename for file() itself, not the caller's
And why the assymetry? Using try/except might help Jython, but that should
be an implementation detail of inspect.currentframe() anyway. line()
should just return inspect.currentframe().f_back.f_lineno
--
Gabriel Genellina
Steve Holden
[...]
> What a lovely langauge.
>
+1 QOTW
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Jeff Schwab
> En Tue, 12 Feb 2008 14:41:20 -0200, Jeff Schwab <je...@schwabcenter.com>
> escribi�:
>
>> def line():
>> try:
>> raise Exception
>> except:
>> return sys.exc_info()[2].tb_frame.f_back.f_lineno
>> def file():
>> return inspect.currentframe().f_code.co_filename
>
> It's not a good idea to shadow the file type; I'd suggest current_file
> and current_line.
>
> file() should return inspect.currentframe().f_back.f_code.co_filename,
> else you're using the filename for file() itself, not the caller's
Both excellent points.
> And why the assymetry? Using try/except might help Jython, but that
> should be an implementation detail of inspect.currentframe() anyway.
> line() should just return inspect.currentframe().f_back.f_lineno
I suspect that Alain was just showing two ways to accomplish the same
end, since he was giving a purely didactic example. I dumbly copied his
code.
What about the following? Should the underscores be omitted from the
method names, for consistency with inspect?
# srcinfo.py
import inspect
import sys
def currentline():
return inspect.currentframe().f_back.f_lineno
def currentfile():
return inspect.currentframe().f_back.f_code.co_filename
# client.py
import srcinfo
import sys
debug = '-d' in sys.argv
# ...
if debug:
print('reached %s:%d' %
(srcinfo.currentfile(), srcinfo.currentline()))
Gabriel Genellina
escribió:
> What about the following? Should the underscores be omitted from the
> method names, for consistency with inspect?
I prefer the names_with_underscore, the "current" style recommended by
PEP8 http://www.python.org/dev/peps/pep-0008/ but hurry up before it
changes!
--
Gabriel Genellina
Jeff Schwab
Right on. Won't I feel silly if the inspect.currentmethods() ever get
renamed,for consistency with the PEP?
It still would be nice to have syntax as clean as __FILE__ and __LINE__.
Has anybody already written a module of syntactic sugar around
inspect? These things are mega-useful while debugging, especially for
those of us who prefer in-language libraries to separate debuggers.
alain
> It still would be nice to have syntax as clean as __FILE__ and __LINE__.
There exists an undocumented builtin called __file__, but
unfortunately no corresponding __line__
Alain
Jeff Schwab
Drat! So close! Thanks for the info. Oh well, I guess special cases
aren't all that special, anyway.
Maybe a function called srcinfo.here() could return a tuple of the file
name and line number, to allow syntax like:
print("The program has reached %f:%d" % srcinfo.here())
Methods names like file_name() and line_no() aren't too hideous, either.
Gabriel Genellina
> There exists an undocumented builtin called __file__, but
> unfortunately no corresponding __line__
There is no __file__ builtin AFAIK; but there is __file__ module attribute
documented here:
http://docs.python.org/ref/types.html#l2h-107
--
Gabriel Genellina
alain
wrote:
> En Wed, 13 Feb 2008 13:07:31 -0200, alain <alainpo...@yahoo.fr> escribió:
>
> > There exists an undocumented builtin called __file__, but
> > unfortunately no corresponding __line__
>
> There is no __file__ builtin AFAIK; but there is __file__ module attribute
> documented here:http://docs.python.org/ref/types.html#l2h-107
>
> --
> Gabriel Genellina
Sorry for the mistake, i should have double-checked.
Alain