On 29 April 2014 17:02, Stefan Krah wrote:
> Mike Miller wrote:
>> I have to say I'm a bit baffled. I expected disagreement, but
>> didn't expect that multiple reasons against would be made up
>> seemingly at random? I and a company I work for (that distributes
>> Py) have been installing Pytho
On 04/30/2014 04:14 AM, Steve Dower wrote:
Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bothered
at its inclusion in the path.
Modifying PATH is not recommended by Microsoft...
Sorry, I mea
Mike Miller wrote:
> I have to say I'm a bit baffled. I expected disagreement, but
> didn't expect that multiple reasons against would be made up
> seemingly at random? I and a company I work for (that distributes
> Py) have been installing Python to ProgramFiles for almost a decade,
> and can a
On 04/30/2014 04:14 AM, Steve Dower wrote:
Here are some more minuses beyond those listed on the issue:
I have to say I'm a bit baffled. I expected disagreement, but didn't expect
that multiple reasons against would be made up seemingly at random? I and a
company I work for (that distribut
Quoting "Stephen J. Turnbull" :
Mike Miller writes:
> However, this bug has been shitcanned for a decade. This is the
> last chance to fix this bug in a branch that's going to be
> supported until 2020!
Probably. I'm not convinced. But that doesn't really matter.
Your bigger concern is
Mike Miller writes:
> However, this bug has been shitcanned for a decade. This is the
> last chance to fix this bug in a branch that's going to be
> supported until 2020!
Probably. I'm not convinced. But that doesn't really matter.
Your bigger concern is the deafening silence from the seni
Mike Miller wrote:
> Every change has pluses and minuses. I can't guarantee 100% benefits, only
> trying to make the case that the benefits here outweigh them.
If this is your case about the benefits, it's a weak case. Feel free to blog
about how to secure a Python installation in multi-user envi
On Mon, Apr 28, 2014 at 11:07 PM, Mike Miller wrote:
> On 04/29/2014 05:12 AM, Steve Dower wrote:
>>
>> This would be an incredibly painful change that would surprise and hurt a
>> lot of
>> people.
>
>
> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
> talking about an
Hi,
Stepping back a bit...
I doubt you'd take the idea this far, but that Python should need assembly by
professionals before use doesn't match its "Batteries Included" spirit, nor the
PC revolution for that matter.
The reason I brought up the subject at 2.7.7 is because there are greater
c
Hi,
Every change has pluses and minuses. I can't guarantee 100% benefits, only
trying to make the case that the benefits here outweigh them.
Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bot
On 04/29/2014 03:07 PM, Stephen J. Turnbull wrote:
> I have no objection *at all* to making the change in the next feature
> release. I think the "good citizenship" argument is more than
> sufficient, ...
> I'm questioning whether it is a sufficient reason to make a backwards-
> incompatible cha
Steven D'Aprano writes:
> On Tue, Apr 29, 2014 at 12:07:00PM +0900, Stephen J. Turnbull wrote:
> > Note that if users actually paid attention to these guidelines, we'd
> > be getting complaints from *them*, not from you. I don't recall ever
> > seeing that. That implies that "normal users" w
On 4/28/2014 8:52 PM, Steven D'Aprano wrote:
I think that's unfair. I'm not a MS fan, not even close. I think their
business practices in the past have been reprehensible. But if there is
anyone who takes backwards-compatibility even more seriously than
Python-Dev, it is them.
I guess there is no
On Tue, Apr 29, 2014 at 12:07:00PM +0900, Stephen J. Turnbull wrote:
> Mike Miller writes:
>
> > Microsoft's guidelines on where to install software are clear, and
> > don't make exceptions that "tools" should be installed to the root
> > of the drive to bypass file system permissions, for conv
Mike Miller writes:
> Microsoft's guidelines on where to install software are clear, and
> don't make exceptions that "tools" should be installed to the root
> of the drive to bypass file system permissions, for convenience.
But there's the rub. In this case, Microsoft doesn't have *security*
On Mon, Apr 28, 2014, at 17:14, Brian Curtin wrote:
> If it's an acceptable change to the release manager (Benjamin?), and
> if there's actually time before the RC (I don't know when it is
> planned), I am willing to backport my 3.3 change to get this in the
> 2.7 installer.
That's fine.
>
> How
On Mon, Apr 28, 2014 at 7:04 PM, Steve Dower wrote:
>> Mike Miller wrote:
>> On 04/29/2014 05:12 AM, Steve Dower wrote:
>>> This would be an incredibly painful change that would surprise and
>>> hurt a lot of people.
>>
>> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
>
> Mike Miller wrote:
> On 04/29/2014 05:12 AM, Steve Dower wrote:
>> This would be an incredibly painful change that would surprise and
>> hurt a lot of people.
>
> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
> talking
> about an installer default, a setting that woul
On Mon, Apr 28, 2014 at 1:56 PM, Mike Miller wrote:
> * watch Dave Beazley's PyCon 2014 talk for a good story involving one
>
>> of those manufacturer installed Pythons:
>> https://www.youtube.com/watch?v=RZ4Sn-Y7AP8
>>
>
> Thanks, I'm trying to get thru all the talk will watch that shortly. ;)
>
On 04/29/2014 08:38 AM, Brian Curtin wrote:
The option to add the current install to your path was added 3.3.
Ok, thanks. So there is some precedent it would be useful.
Remember, python-dev's are not the target users of this package, and are a
rather minuscule fraction of the user base.
K
2.7.7. on Windows
Message-ID:
<771463774420395726.352685sturla.molden-gmail@news.gmane.org>
"C:\Program Files\Python27" contains an empty space in the path. If you
want to randomly break build tools for C extensions, then go ahead and
ch
On Mon, Apr 28, 2014 at 3:07 PM, Mike Miller wrote:
>
> On 04/29/2014 05:12 AM, Steve Dower wrote:
>>
>> This would be an incredibly painful change that would surprise and hurt a
>> lot of
>> people.
>
>
> Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
> talking about an
On 04/29/2014 05:12 AM, Steve Dower wrote:
This would be an incredibly painful change that would surprise and hurt a lot of
people.
Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
talking about an installer default, a setting that would still be changeable as
it alw
On Mon, 28 Apr 2014 19:52:48 +1200
Mike Miller wrote:
>
> I thought this might be a good time to make a final plea to fix a
> long-standing security issue in the installer on Windows. By default it
> installs Python to the root folder, thereby bypassing filesystem permissions:
>
> http://bugs.p
Mike Miller wrote:
> I thought this might be a good time to make a final plea to fix a
> long-standing security issue in the installer on Windows. By default it
> installs
> Python to the root folder, thereby bypassing filesystem permissions:
>
>http://bugs.python.org/issue1284316
This would be a
Mike Miller wrote:
> The main rationale given (for not using the standard %ProgramFiles%) has been
> that the full path to python is too long to type, and ease of use is more
> important than the security benefits given by following Windows conventions.
"C:\Program Files\Python27" contains an
Greetings,
I've just woken up and noticed Python 2.7.7 is on track to be released, and in a
rather unique event contains a few security enhancements
in addition to the usual fixes:
http://legacy.python.org/dev/peps/pep-0466/
I thought this might be a good time to make a final plea to fix a
lo
27 matches
Mail list logo
