PyWart: Exception error paths far too verbose

Rick Johnson rantingrickjohnson at
Wed Jan 16 17:31:24 CET 2013

On Wednesday, January 16, 2013 8:20:12 AM UTC-6, Michael Torrie wrote:
> On 01/15/2013 10:59 PM, Rick Johnson wrote:
> > Why do i need to see "C:\users\user\documents\python\lib" EVERY time?
> You're thinking about things from a very windows-centric point of view.

How are file paths or directories a windows _only_ point of view. Last time i checked, the other "big two" supported such features.
> There are many cases where as a developer I need to see the full paths.

Yes i agree, but not if those files exist in you dev library.

>  My modules are not always going to be in a common subfolder.  

Well they should be, however, there are a few valid exceptions. 

> Django
> apps, for example, live in an arbitrary folder, in my case,
> /var/www/apps on my web server.  

And a web server would be a valid exception -- granted that the web sever is NOT your actual library folder, if it were the path could be shortened.

> Sometimes they live in my home projects
> folder.  Django itself lives partly in /usr/lib/python2.7/site-packages
> and partly in /usr/share/django. Granted most of my errors are going to
> happen in my own code, which is in /var/www/apps/blah.  But occasionally
> I might uncover a django bug (less likely of course).  Seeing the full
> path is essential for me.  

And under my plan you WILL see the whole path _IF_ the django folder is NOT your "registered"[1] lib folder. 

> As well, runtime errors get logged as the
> system is serving, and they could come from any of my apps, depending on
> how bad a programmer I am.
> Finally, in an ideal world, all runtime errors should be trapped by the
> program.  The end user should never see them.  

Who said anything about end users? My comments are for developer ears only.

> Traces are for developers, not users.

This comment ignores the main point, but i agree.

[1] Whether a dev must register a lib folder or use a predetermined folder is yet to be decided.

More information about the Python-list mailing list