[Pyrex] Re: callback

[Bryan Weingarten]

bob,

i thought of that, but decided against that since i would have to modify 
the pyrex source everytime a new version of pyrex came out and i would 
have to have other developers modify their code too.  you might be right 
that modifying pyrex source would be easier though, but i've never 
looked at the guts of pyrex yet... should be easy enough to find 
though.   thanks for reminding me about this option.

bryan

Bob Ippolito wrote:

> It probably would be nice to have an option that strips the 
> "/opt/local/greg_wears_army_boots/my_project" and just leaves 
> file.pyx.  Or some option to strip "debugging" information 
> altogether.  Have you tried modifying the Pyrex source instead of 
> modifying the output?  It sounds like a change that would be trivial 
> to make, I'm surprised you didn't just do that.
>
> -bob
>
> On Nov 10, 2003, at 10:37 PM, Bryan Weingarten wrote:
>
>> greg,
>>
>> i'm sorry, but i have to disagree with you on one point.  everyone in 
>> my company (since i work in a security company) would tell you that 
>> writing the fully qualified path to an internal machine is a security 
>> risk.  in addition to that, i may have a directory in my path that i 
>> wouldn't want hard-coded and have the public see, such as
>>
>> /opt/local/greg_wears_army_boots/my_project/file.pyx
>>
>> IMO,  the comments and __pyx_filenames[] should default to the 
>> filename.pyx and if i want to have a prefix a can set a global 
>> variable in the pyrex code itself or a value in setup.py.
>>
>> currently, our solution is to just compile the pyx file to a c file, 
>> run a script that strips all commonts and __pyx_filenames of there 
>> full path and leaves the filename.  then compile the c file.  
>> manually modifying the c file seems like a hack, but at this point, 
>> this is the only way i'm allowed to use pyrex.  currenly, the python 
>> extension generated by pyrex won't pass our QA department until the 
>> internal names are removed.
>>
>> thanks,
>>
>> bryan
>>
>> Greg Ewing wrote:
>>
>>>> i was surprised by the stack trace which is below.  notice that the
>>>> fully qualified path to the machine it was built on is displayed.  i
>>>> would really like pyrex not to include the fully qualified path to my
>>>> internal development machine.  is there a way to fix this?
>>>>
>>>
>>> Pyrex includes the full pathname at present in the interests
>>> of uniquely identifying the file. I suppose I could change this,
>>> if it's really worrying people, at the expense of the file no
>>> longer being uniquely identified.
>>>
>>> Note that the situation is slightly different from displaying the name
>>> of a Python file in the traceback. The Python file must exist
>>> somewhere on the user's machine, so it makes sense to display a
>>> pathname to the users' version of it. But the Pyrex source file isn't
>>> necessarily on the user's machine at all, so displaying its pathname
>>> on the original machine might not be worse than displaying anything
>>> else...
>>>
>>> Greg Ewing, Computer Science Dept, 
>>> +--------------------------------------+
>>> University of Canterbury,       | A citizen of NewZealandCorp, a      |
>>> Christchurch, New Zealand       | wholly-owned subsidiary of USA 
>>> Inc.  |
>>> greg at cosc.canterbury.ac.nz       
>>> +--------------------------------------+
>>>
>>> _______________________________________________
>>> Pyrex mailing list
>>> Pyrex at lists.copyleft.no
>>> http://lists.copyleft.no/mailman/listinfo/pyrex
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Pyrex mailing list
>> Pyrex at lists.copyleft.no
>> http://lists.copyleft.no/mailman/listinfo/pyrex
>