Personally I would like to see py have the ability to *not* generate .pyc files. 99% of the time generation of .pyc doesn't make much difference to me, but there are times where you simply cannot generate them. For example . . . TiVo consists of 4 partitions: - primary root (ro) - primary /var (rw) - secondary root (ro) - secondary /var (rw) The idea is that with / mounted ro, the box can never fargle itself to the point where a user issued fsck is required. This is pretty sweet for devices where the consumer has no idea that an actual Linux OS (or *any* OS for that matter) is installed. I made an unsuccessful attempt to load python onto my TiVo, but when I realized the ro nature of the / filesystem it forced me to reconsider my entire effort. Likewise, another project of mine is on a rackmount device, and we've briefly talked about making / ro in order to achieve the same safety: we don't want the discuss fargled so badly that a customer calls us up and we step them through a fsck. Likewise, we *use* py on our box. Thus, forcing the interpretter to *not* generate .pyc would be a benefit to us, as it would allow us to improve the stability of our platform. Just my 2 cents. -c -- 2:00pm up 103 days, 5:35, 1 user, load average: 5.73, 5.52, 5.26