On 17/01/2008, Christian Heimes [EMAIL PROTECTED] wrote:
* Should the Windows installer add %APPDATA%/Python/Scripts to PATH?
The Windows installers currently do not add the main Python\Scripts
directory to PATH, so they shouldn't add this one either.
Paul
On 07:55 am, [EMAIL PROTECTED] wrote:
A CC of the mail goes to the authors of setuptools, virtual python,
working env and virtual env. What's your opinion on the PEP? Do you
have
some input and advice for me?
I wrote a similar tool called Combinator
On 17 Jan, 2008, at 8:55, Christian Heimes wrote:
The PEP 370 (http://www.python.org/dev/peps/pep-0370) per user site
packages directory has several open questions:
* Are the directories for Windows, Mac and Unix fine?
The Mac directories look fine to me.
Is it worthwhile to note in the
Ronald Oussoren wrote:
The Mac directories look fine to me.
Is it worthwhile to note in the PEP that the directories for the Mac are
already used in Python 2.5?
Good point!
* Mac: Should framework and non-framework builds of Python use
the same directories?
Yes, because that makes
* Are the directories for Windows, Mac and Unix fine?
Regarding Windows, I personally think its OK (but I also personally think
the status-quo is OK too). As has already been mentioned in this thread,
Windows actually provides an API you can call to determine various well
known folders. I
Mark Hammond wrote:
* Are the directories for Windows, Mac and Unix fine?
Regarding Windows, I personally think its OK (but I also personally think
the status-quo is OK too). As has already been mentioned in this thread,
Windows actually provides an API you can call to determine various
On Thu, 17 Jan 2008 08:55:51 +0100, Christian Heimes [EMAIL PROTECTED] wrote:
* Should the site package directory also be ignored if process
gid != effective gid?
If it should, I think the PEP should explain the attack this defends
against in more detail. The current brief mention of security
Isn't SHGetSpecialFolderPath() XP and newer only?
MSDN documents:
Minimum operating systems Windows 2000, Windows NT 4.0 with Internet
Explorer 4.0, Windows 98, Windows 95 with Internet Explorer 4.0
The patch is available at
http://bugs.python.org/issue1763. Maybe you have some time to review
Christian Heimes wrote:
I'll justify why I view Python as a roaming app. All
company and university Linux boxes I've used in the past had exported
$HOME via NFS. So ~/.local is roamed.
I think there is a slight subtlety here: the exported NFS
$HOME is more equivalent to the HOMEDRIVE/HOMEPATH
On Thu, 17 Jan 2008 13:09:34 +0100, Christian Heimes [EMAIL PROTECTED] wrote:
Jean-Paul Calderone wrote:
If it should, I think the PEP should explain the attack this defends
against in more detail. The current brief mention of security issues
is a bit hand-wavey. For example, what is the
Christian Heimes wrote:
Tim Golden wrote:
Christian Heimes wrote:
I'll justify why I view Python as a roaming app. All
company and university Linux boxes I've used in the past had exported
$HOME via NFS. So ~/.local is roamed.
I think there is a slight subtlety here: the
Jean-Paul Calderone wrote:
If it should, I think the PEP should explain the attack this defends
against in more detail. The current brief mention of security issues
is a bit hand-wavey. For example, what is the relationship between
security, this feature, and the PYTHONPATH environment
On 17 Jan, 2008, at 9:40, [EMAIL PROTECTED] wrote:
On 07:55 am, [EMAIL PROTECTED] wrote:
The PEP 370 (http://www.python.org/dev/peps/pep-0370) per user site
packages directory has several open questions:
* Are the directories for Windows, Mac and Unix fine?
* Mac: Should framework and
Tim Golden wrote:
Christian Heimes wrote:
I'll justify why I view Python as a roaming app. All
company and university Linux boxes I've used in the past had exported
$HOME via NFS. So ~/.local is roamed.
I think there is a slight subtlety here: the exported NFS
$HOME is more equivalent to
[EMAIL PROTECTED] wrote:
discussion of per-user directories on different platforms
One of the problems we've encountered over and over again with
Combinator is that MacOS has a dual personality. Its personality is not
just an issue of framework vs. non-framework build, but a fundamental
Christian Heimes wrote:
Tim Golden wrote:
The difference therefore is that installing large quantities
of Python modules into a roaming profile path will involve
their being copied to-and-fro on logon/logoff which, historically
at least, was a known cause of slow startup/shutdown. I'll
try
On 12:02 pm, [EMAIL PROTECTED] wrote:
On 17 Jan, 2008, at 9:40, [EMAIL PROTECTED] wrote:
On 07:55 am, [EMAIL PROTECTED] wrote:
The framework build of Python definitly targets the upper layer of the
OSX stack, not just the Unix core. This sometimes causes confusion,
but mostly from
On 12:19 pm, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
MacOS isn't the only platform that has this problem. I use cygwin
under
Windows, and I wish Python (whether or not a cygwin build) would also
use ~/.local.
I would like to agree. MacOS has an advantage here though. Windows,
even
On 12:26 pm, [EMAIL PROTECTED] wrote:
On Thu, 17 Jan 2008 13:09:34 +0100, Christian Heimes [EMAIL PROTECTED]
wrote:
The uid and gid tests aren't really required. They just provide an
extra
safety net if a user forgets to add the -s flag to a suid app.
It's not much of a safety net if
On 17/01/2008, Tim Golden [EMAIL PROTECTED] wrote:
Is %USERPROFILE% not equal to %HOMEDRIVE%%HOMEPATH%?
No. On my machine, for example:
HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\vogbs022\it\goldent
USERPROFILE=C:\Documents and Settings\goldent
However, using an account without a mapped home
The best we can hope for is to point to HOMEDRIVE/PATH as
Paul suggested (*possibly* rewiring os.path.expanduser to
try that first, depending on Win2K stuff)
os.path.expanduser uses HOMEDRIVE/HOMEPATH. It checks for an explicit
HOME (set manually by the user, this isn't a Windows standard
On 17 Jan, 2008, at 14:22, [EMAIL PROTECTED] wrote:
On 12:02 pm, [EMAIL PROTECTED] wrote:
On 17 Jan, 2008, at 9:40, [EMAIL PROTECTED] wrote:
On 07:55 am, [EMAIL PROTECTED] wrote:
The framework build of Python definitly targets the upper layer of
the OSX stack, not just the Unix core.
On 17 Jan, 2008, at 14:22, [EMAIL PROTECTED] wrote:
As long as the default installation location is still ~/Library/
Python/ X.Y for framework builds I wouldn't mind too much.
Is there a default installation location? When we started this
part of the discussion, it was just which paths
Paul Moore wrote:
On 17/01/2008, Tim Golden [EMAIL PROTECTED] wrote:
Is %USERPROFILE% not equal to %HOMEDRIVE%%HOMEPATH%?
No. On my machine, for example:
HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\vogbs022\it\goldent
USERPROFILE=C:\Documents and Settings\goldent
However, using an account
Paul Moore wrote:
The best we can hope for is to point to HOMEDRIVE/PATH as
Paul suggested (*possibly* rewiring os.path.expanduser to
try that first, depending on Win2K stuff)
os.path.expanduser uses HOMEDRIVE/HOMEPATH. It checks for an explicit
HOME (set manually by the user, this isn't a
Ronald Oussoren wrote:
I'm pretty sure I've seen a suggestion for a distutils options for
installing into your home location (something like python setup.py
install --user).
If you have read the PEP then I'm pretty sure that you have read about
the python setup.py install --user thing. ;)
Tim Golden wrote:
If it had its priorities switched around, Christian's patch could simply
call os.path.expanduser.
No, I can't use expanduser(~) because there is no sensible way to get
from the path to APPDATA. In it's infinite wisdom MS has decided to
localize the name of its shell folders.
Paul Moore wrote:
The one downside of following expanduser is that Christian's code is
in C, where ntpath.expanduser is in Python, so there are 2 versions to
keep in sync. Maybe Christian could expose his C implementation, which
ntpath.expanduser could then reuse?
What code are you talking
On 17/01/2008, Tim Golden [EMAIL PROTECTED] wrote:
Ummm... see my earlier point a few posts back which refers
to r54364 which gave priority to USERPROFILE over HOMEDRIVE/HOMEPATH
Sorry. I'd not realised this was a post-2.5 revision (ie, not in
released code yet...)
Looking at the change, it
Christian Heimes wrote:
Paul Moore wrote:
I'd recommend that this change be reverted. To correctly get another
user's home directory would involve reading (via the registry, or
maybe some utility function I couldn't find at a quick glance) the
value of HOMEDRIVE/HOMEPATH which is set for the
Paul Moore wrote:
I'd recommend that this change be reverted. To correctly get another
user's home directory would involve reading (via the registry, or
maybe some utility function I couldn't find at a quick glance) the
value of HOMEDRIVE/HOMEPATH which is set for the other user. (In fact,
[EMAIL PROTECTED] wrote:
My suggestion would be to have *both* ~/.local *and* ~/Library/Python be
honored on the Mac, because there really isn't much harm in doing so.
Perhaps it would make sense for non-framework builds to not honor
~/Library/Python, but I am pretty certain, based on
Tim Golden wrote:
Frustratingly, I don't believe there's *any* canonical
way to find ~user without actually going through the whole
process of getting a token and impersonating them. If
they've logged onto this machine already you can have
a good go by following the code posted the other day
Ronald Oussoren wrote:
Ah, so ~/.local is just a per-user variation on /usr/local? I didn't
even know of that convention before this thread started, I tend to use
~/local (without dot) instead.
I assume ~/.local was first introduced by the freedesktop.org people. On
my box it's only used for
On Jan 17, 2008, at 4:05 PM, Christian Heimes wrote:
I assume ~/.local was first introduced by the freedesktop.org
people. On
my box it's only used for some desktop related apps like
~/.local/share/Trash or XFC4.
I've only seen ~/.local/ defined there, and only ~/.local/share/ in
that
If I run make clean and then make, builting _ctypes fails with this message:
*** WARNING: renaming _ctypes since importing it failed: No module
named _weakref
Typing make a second time fixes this -- it seems a simple matter of
_ctypes being built before _weakref.
--
--Guido van Rossum (home
I believe the issue of whether and how to backport bytes (and
bytearray?) from 3.0 to 2.6 has come up before, but I don't think
we've come to any kind of conclusion. It's quite subtle. In a private
email, Thomas Wouters and I discussed this:
[Guido]
Perhaps the biggest question in my mind is
[GvR]
I believe the issue of whether and how to backport bytes
(and bytearray?) from 3.0 to 2.6 has come up before, but
I don't think we've come to any kind of conclusion.
My recommendation is to leave it out of 2.6.
Not every 3.0 concept has to be backported. This particular one doesn't
On Jan 17, 2008 6:00 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
[GvR]
I believe the issue of whether and how to backport bytes
(and bytearray?) from 3.0 to 2.6 has come up before, but
I don't think we've come to any kind of conclusion.
My recommendation is to leave it out of 2.6.
*If* we provide some kind of backport of
bytes (even if it's just an alias for or trivial
subclass of str), it should be part of a strategy
that makes it easier to write code that
runs under 2.6 and can be automatically translated
to run under 3.0 with the same semantics.
If it's just an
I found this posting, and those following it, as I too am baffled that
NamedTemporaryFile doesn't let you read the generated file - even within the
same script.
For unit testing it is very commonplace to generate a test file on the fly
and then use it as input the function being tested.
On Jan 17, 2008 7:11 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
*If* we provide some kind of backport of
bytes (even if it's just an alias for or trivial
subclass of str), it should be part of a strategy
that makes it easier to write code that
runs under 2.6 and can be automatically
Don't close it until you're done with it. Isn't that obvious?
On Jan 17, 2008 8:30 PM, [EMAIL PROTECTED] wrote:
I found this posting, and those following it, as I too am baffled that
NamedTemporaryFile doesn't let you read the generated file - even within the
same script.
For unit testing it
Raymond Hettinger writes:
One other thought. I'm guessing that apps that would
care about the distinction are already using unicode
and are already treating text as distinct from arrays
of bytes.
Indeed. Mailman, for instance. Yet Mailman still has problems with
(broken) wire protocol
Thank you very much for the quick reply.
I believe we have to close the file in order be able to read it in - in this
case to feed a unittest. I actually tried to read it in before closing it,
but (as I suspected) the data wasn't available.
We use unit testing for pretty much all functions and
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Is it reading text or binary data from stream blah? We can't tell. If
| it's meant to be reading text, 2to3 should leave it alone. But if it's
| meant to be reading binary data, 2to3 should change the string
| literals
having b and bytes as aliases for and
str in 2.6 would mean that we could write 2.6 code that correctly
expresses the use of binary data -- and we could use u and unicode
for code using text, and 2to3 would translate those to and str and
the code would be correct 3.0 text processing code.
On 04:43 am, [EMAIL PROTECTED] wrote:
Just being able to (voluntarily! on a
per-module basis!) use a different type name and literal style for
data could help forward-looking programmers get started on making the
distinction clear, thus getting ready for 3.0 without making the jump
just yet (or
[EMAIL PROTECTED] wrote:
Thank you very much for the quick reply.
I believe we have to close the file in order be able to read it in - in this
case to feed a unittest. I actually tried to read it in before closing it,
but (as I suspected) the data wasn't available.
Did you try seeking
Guido van Rossum schrieb:
If I run make clean and then make, builting _ctypes fails with this
message:
*** WARNING: renaming _ctypes since importing it failed: No module
named _weakref
Typing make a second time fixes this -- it seems a simple matter of
_ctypes being built before
Guido van Rossum schrieb:
I believe the issue of whether and how to backport bytes (and
bytearray?) from 3.0 to 2.6 has come up before, but I don't think
we've come to any kind of conclusion. It's quite subtle. In a private
email, Thomas Wouters and I discussed this:
[Guido]
Perhaps the
51 matches
Mail list logo
