Re: [Python-Dev] disable writing .py[co]

Martin> * Doesn't solve the original problem: many processors writing to Martin> the same file system (unless you manage to set an environment Martin> variable differently on each node). Sure: export PYCROOT=/tmp/`hostname --fqdn` Skip

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

If a .pyc file can't be written, this error is silently ignored and the .py file is compiled each time. A feature to suppress writing .pyc files isn't needed to support having Python installed on a read-only filesystem. --Guido van Rossum (home page: http://www.python.org/~guido/)

Christopher> Personally I would like to see py have the ability to *not* Christopher> generate .pyc files. 99% of the time generation of .pyc Christopher> doesn't make much difference to me, but there are times Christopher> where you simply cannot generate them. For example . . . See PEP 304. That's one of the options. Skip

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

If a .pyc file can't be written, this error is silently ignored and the .py file is compiled each time. A feature to suppress writing .pyc files isn't needed to support having Python installed on a read-only filesystem. --Guido van Rossum (home page: http://www.python.org/~guido/)

Christopher> Personally I would like to see py have the ability to *not* Christopher> generate .pyc files. 99% of the time generation of .pyc Christopher> doesn't make much difference to me, but there are times Christopher> where you simply cannot generate them. For example . . . See PEP 304. That's one of the options. Skip
participants (3)
-
Christopher Blunck
-
Guido van Rossum
-
Skip Montanaro