Russell E. Owen wrote:
This in turn implies that we may have to give up some support for
dragging python modules into site-packages, e.g. not generate .pyc files
for such modules. At least if we go that route it will mostly affect
power users, who can presumably cope.
And when someone
Isaac Morland wrote:
the
benefit to me and to Greg and to others writing .py code is that our
directories will contain *.py and __pycache__, rather than *.py and
*.pyc. So it will be much easier to see what is actually there.
Yes. When using MacOSX I do most of my work using the
Finder's
Matthias Klose d...@ubuntu.com writes:
On 23.03.2010 02:28, Ben Finney wrote:
Perhaps also of note is that the FHS recommends systems use
‘/var/cache/foo/’ for cached data from applications:
/var/cache : Application cache data
Purpose
/var/cache is intended for
Antoine Pitrou wrote:
or if a user installs by dragging into
site-packages instead of using an installer?
Well... do people actually do this?
Yes. We do it all the time with unpackaged only-for-internal-use Python
code.
I wouldn't expect it to work with random packages downloaded from the
On Wed, 24 Mar 2010 12:35:43 am Ben Finney wrote:
Matthias Klose d...@ubuntu.com writes:
On 23.03.2010 02:28, Ben Finney wrote:
Perhaps also of note is that the FHS recommends systems use
‘/var/cache/foo/’ for cached data from applications:
/var/cache : Application cache data
In article 4ba80418.6030...@canterbury.ac.nz,
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Antoine Pitrou wrote:
In light of this issue, I'm -0.5 on __pycache__ becoming the default
caching
mechanism. The directory ownership/permissions issue is too much of a mess,
especially for
Antoine Pitrou wrote:
The main point of the __pycache__ proposal is to solve the needs of
Ubuntu/Debian packagers. If you are developing (rather than deploying or
building packages), you shouldn't have these needs AFAICT.
Maybe it's one point, but I'm not sure it's the *main* one.
Personally
Russell E. Owen wrote:
If .pyc files are to be shared, it seems essential to (by default)
generate them at install time and make them read-only for unprivileged
users.
This in turn implies that we may have to give up some support for
dragging python modules into site-packages
No, I don't
On Mar 22, 2010, at 08:33 PM, Antoine Pitrou wrote:
Well, precisely. That's why I suggest that creating the __pycache__
directories be done *at install time* (or packaging time), and not via the
core import machinery (that is, not at import time). That is, when you *know*
you are the right user,
On Mar 24, 2010, at 12:35 AM, Ben Finney wrote:
So what? There's no implication that data-which-happens-to-be-code is
unsuitable for storage in ‘/var/cache/foo/’. Easily-regenerated Python
byte code for caching meets the description quite well, AFAICT.
pyc files don't go there now, so why would
On Mar 23, 2010, at 12:49 PM, Russell E. Owen wrote:
If .pyc files are to be shared, it seems essential to (by default)
generate them at install time and make them read-only for unprivileged
users.
I think in practice this is what's almost always going to happen for system
Python source,
Antoine Pitrou solip...@pitrou.net writes:
Steven D'Aprano st...@pearwood.info writes:
On Wed, 24 Mar 2010 12:35:43 am Ben Finney wrote:
On 23.03.2010 02:28, Ben Finney wrote:
URL:http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
#VARCACHEAPPLICATIONCACHEDATA
This
Le mardi 23 mars 2010 à 20:50 -0400, Isaac Morland a écrit :
I'm sure Greg will jump in if I'm wrong about what he is saying, but the
benefit to me and to Greg and to others writing .py code is that our
directories will contain *.py and __pycache__, rather than *.py and *.pyc.
So it will
I have a pretty good start on PEP 3147 implementation [1], but I've
encountered a situation that I'd like to get some feedback on. Here's the
test case illustrating the problem. From test_import.py:
def test_writable_directory(self):
# The umask is not conducive to creating a
Or maybe you have a better idea? What's the equivalent situation on Windows
and how would things work there?
On Windows, this problem is easy: create the directory with no
specification of an ACL, and it will (usually) inherit the ACL of the
parent directory. IOW, the same users will have
refuse to create __pycache__ if I can't create it with the same ownership
and permissions as the parent directory (and raise an ImportWarning).
I don't think an ImportWarning should be raised: AFAICT, we are not
raising one, either, when the pyc file cannot be created (and it may
well be
On Mar 22, 2010, at 02:30 PM, Antoine Pitrou wrote:
Barry Warsaw barry at python.org writes:
* Tough luck
* Force the umask so that the directory is writable, but then the question
is,
by whom? ugo+w or something less?
* Copy the permissions from the parent directory and ignore umask
On Mon, Mar 22, 2010 at 06:56, Barry Warsaw ba...@python.org wrote:
I have a pretty good start on PEP 3147 implementation [1], but I've
encountered a situation that I'd like to get some feedback on. Here's the
test case illustrating the problem. From test_import.py:
def
Antoine Pitrou wrote:
In light of this issue, I'm -0.5 on __pycache__ becoming the default caching
mechanism. The directory ownership/permissions issue is too much of a mess,
especially for Web applications (think __pycache__ files created by the Apache
user).
Doesn't the existing .pyc
On 22Mar2010 09:56, Barry Warsaw ba...@python.org wrote:
| I have a pretty good start on PEP 3147 implementation [1], but I've
| encountered a situation that I'd like to get some feedback on. Here's the
| test case illustrating the problem. From test_import.py:
|
| def
On 23Mar2010 11:40, I wrote:
| | * Raise an exception or refuse to create __pycache__ if it's not writable
| | (again, by whom?)
|
| -3
| Bleah. My python program won't run because an obscure (to the user)
| directory had unusual permissions?
Clarification: I'm -3 on the exception. Silent
Antoine Pitrou solip...@pitrou.net writes:
Barry Warsaw barry at python.org writes:
When Python is being installed, either by a from-source 'make
install' or by the distro packager, then you'd expect the umask not
to be insane. In the latter case, it's a bug and in the former case
you
On 23.03.2010 02:28, Ben Finney wrote:
Antoine Pitrousolip...@pitrou.net writes:
Barry Warsawbarryat python.org writes:
When Python is being installed, either by a from-source 'make
install' or by the distro packager, then you'd expect the umask not
to be insane. In the latter case, it's
23 matches
Mail list logo
