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
(http://divmod.org/trac/wiki/DivmodCombin
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 P
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
> * 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 as
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 variou
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 "sec
> 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 revi
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/HOMEPAT
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 i
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 su
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 equiva
[EMAIL PROTECTED] wrote:
> 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
> question of "is this platform a UNIX or is it not a UN
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'l
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 developers
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,
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
> 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 na
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. This
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,
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
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
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 ex
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
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 f
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 (
Paul Moore gmail.com> writes:
>
> Yes, this does contradict the Microsoft guideline that you shouldn't
> write to USERPROFILE, but Microsoft themselves set HOMEDRIVE and
> HOMEPATH, so they vioated the guidelines, not us .
>
> The point here is that we want "the user's home". This is clearly
> %
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 w
[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 h
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
> *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
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. NamedTempor
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 a
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 testi
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 proto
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 c
"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
| liter
> 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 proces
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 (o
[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 seekin
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
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]
>> > Perha
52 matches
Mail list logo
