[Pyrex] Re: callback

[Bob Ippolito]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20031110/3ee884fd/smime.bin