Python equivt of __FILE__ and __LINE__

B

Bill Davy

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

PS www.SynectixLtd.com is not relevant
 
G

Gary Herron

Bill said:
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

PS www.SynectixLtd.com is not relevant
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
 
T

thebjorn

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
 
A

alain

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

PSwww.SynectixLtd.comis not relevant

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
 
B

Bill Davy

thebjorn said:
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.

Bill

PS www.SynectixLtd.com is not relevant
 
J

Jeff Schwab

alain said:
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

PSwww.SynectixLtd.comis not relevant

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

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))
 
G

Gabriel Genellina

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
 
J

Jeff Schwab

Gabriel said:
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()))
 
J

Jeff Schwab

Gabriel said:
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!

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.
 
A

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
 
J

Jeff Schwab

alain said:
There exists an undocumented builtin called __file__, but
unfortunately no corresponding __line__

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top