Python equivt of __FILE__ and __LINE__

[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

 

[Gary Herron]

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

 

[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

 

[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

 

[Bill Davy]

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

 

[Jeff Schwab]

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

 

[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

 

[Steve Holden]

Bill Davy wrote:
[...]

> What a lovely langauge.

+1 QOTW

 

[Jeff Schwab]

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]

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!

 

[Jeff Schwab]

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.

 

[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]

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.

 

[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

 

[alain]

There is no __file__ builtin AFAIK; but there is __file__ module attribute  
documented here:http://docs.python.org/ref/types.html#l2h-107

Sorry for the mistake, i should have double-checked.

Alain