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 colu
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 d
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 w
Antoine Pitrou writes:
Steven D'Aprano writes:
> On Wed, 24 Mar 2010 12:35:43 am Ben Finney wrote:
> > > On 23.03.2010 02:28, Ben Finney wrote:
> > > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
> > > >#VARCACHEAPPLICATIONCACHEDATA>
> > > >
> > > > This would suggest that Pyth
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, eit
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 woul
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 use
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 t
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 I
In article <4ba80418.6030...@canterbury.ac.nz>,
Greg Ewing 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 Web applications (
On Wed, 24 Mar 2010 12:35:43 am Ben Finney wrote:
> Matthias Klose 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
>
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
Matthias Klose 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 ca
On 23.03.2010 02:28, Ben Finney wrote:
Antoine Pitrou writes:
Barry Warsaw 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 ca
Antoine Pitrou writes:
> Barry Warsaw 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 screwed up so y
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 failu
On 22Mar2010 09:56, Barry Warsaw 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 test_writable_directory(self):
|
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 mechani
On Mon, Mar 22, 2010 at 06:56, Barry Warsaw 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 test_writable_directory(self)
On Mar 22, 2010, at 02:30 PM, Antoine Pitrou wrote:
>Barry Warsaw 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 um
> 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 t
> 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 wri
22 matches
Mail list logo
