[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Python equivt of __FILE__ and __LINE__

Bill Davy

2/11/2008 9:59:00 AM

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


14 Answers

Gary Herron

2/11/2008 3:55:00 PM

0

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

2/11/2008 7:25:00 PM

0

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
>
> > PSwww.SynectixLtd.comis 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

I think the inspect module might be more useful... the getfile() and
getsourcelines() look promising.

-- bjorn

alainpoint

2/12/2008 8:19:00 AM

0

On Feb 11, 10:58 am, "Bill Davy" <B...@SynectixLtd.com> 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
>
> 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

2/12/2008 12:06:00 PM

0

"thebjorn" <BjornSteinarFjeldPettersen@gmail.com> wrote in message
news:a9946b83-22f8-4da5-8ae4-fed8c367ff90@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
>>
>> >
>>
>> 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


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

2/12/2008 4:41:00 PM

0

alain wrote:
> On Feb 11, 10:58 am, "Bill Davy" <B...@SynectixLtd.com> 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
>>
>> 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

2/12/2008 5:46:00 PM

0

En Tue, 12 Feb 2008 14:41:20 -0200, Jeff Schwab <jeff@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

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

2/12/2008 5:59:00 PM

0

Bill Davy wrote:
[...]
> What a lovely langauge.
>
+1 QOTW
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.hold...

Jeff Schwab

2/12/2008 6:20:00 PM

0

Gabriel Genellina wrote:
> En Tue, 12 Feb 2008 14:41:20 -0200, Jeff Schwab <jeff@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

2/12/2008 6:39:00 PM

0

En Tue, 12 Feb 2008 16:20:12 -0200, Jeff Schwab <jeff@schwabcenter.com>
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... but hurry up before it
changes!

--
Gabriel Genellina

Jeff Schwab

2/12/2008 6:44:00 PM

0

Gabriel Genellina wrote:
> En Tue, 12 Feb 2008 16:20:12 -0200, Jeff Schwab <jeff@schwabcenter.com>
> 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... 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.