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
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 writabl
23 matches
Mail list logo
