Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 9:58 AM, Donald Stufft wrote: > Now this does not mean that ``pip install cdecimal`` will automatically > install > this, because whether or not you're willing to install from servers other than > PyPI[1] is a policy decision for the end user of pip. I f

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 10:11 AM, R. David Murray wrote: > On Thu, 08 May 2014 09:58:08 -0400, Donald Stufft wrote: >> I don't think the warning is FUD, and it doesn't mention anything security >> related at all. The exact text of the warning is in the sub

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 10:21 AM, R. David Murray wrote: > On Thu, 08 May 2014 10:11:39 -0400, "R. David Murray" > wrote: >> On Thu, 08 May 2014 09:58:08 -0400, Donald Stufft wrote: >>> I don't think the warning is FUD, and it doesn't mention anything se

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

gure out how to re-execute the >> command so that it does try. > > Agreed. That warning looks rather pointless and only aimed at trying to > enforce the pip developers' ideological preferences. > > Regards > > Antoine. > The pip developers didn’t make this decision.

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 10:36 AM, Stefan Krah wrote: > Donald Stufft wrote: >> There is support for trusted externally hosted packages, you put the URL in >> PyPI and include a hash in the fragment like so: >> >> http://www.bytereef.org/software/mpdecimal/relea

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 11:19 AM, Stefan Krah wrote: > Donald Stufft wrote: >> hosted packages are brittle and more prone to failure. Every single external >> server adds *another* SPOF into any particular install set. Even if every >> external server has a 99.9% uptime, when

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 11:21 AM, R. David Murray wrote: > On Thu, 08 May 2014 10:37:15 -0400, Donald Stufft wrote: >> Most users are not going to care up until the point where the external server >> is unavailable, and then they care a whole lot. On the tin it sounds >>

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 11:34 AM, Stefan Krah wrote: > Donald Stufft wrote: >>> Today I've switched to manual install mode with manual sha256sum >>> verification >>> which is *far* safer than anything you get via pip right now. >> >> It is not safer

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 11:37 AM, M.-A. Lemburg wrote: > On 08.05.2014 16:42, M.-A. Lemburg wrote: >> On 08.05.2014 15:58, Donald Stufft wrote: >>> >>> On May 8, 2014, at 9:39 AM, M.-A. Lemburg wrote: >>> >>>> Well, to be fair and leaving asid

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 12:03 PM, Stefan Krah wrote: > Donald Stufft wrote: >> I said ?meaningful?. Almost nobody is going to ever bother googling it and >> the likelihood that someone is able to MITM *you* specifically is far lesser >> than the likelihood that someone is goi

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 12:42 PM, R. David Murray wrote: > On Thu, 08 May 2014 11:32:28 -0400, Donald Stufft wrote: >> On May 8, 2014, at 11:21 AM, R. David Murray wrote: >>> Ah, I understand now. >>> >>> Your perspective is as someone who is using pip for *de

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 5:02 PM, Paul Moore wrote: > On 8 May 2014 16:46, Donald Stufft wrote: >> Anything can be changes or reconsidered of course. I feel pretty strongly >> that >> an installer should not install things from places other than the index >> without

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 6:20 PM, Nick Coghlan wrote: > > On 9 May 2014 07:23, "Donald Stufft" wrote: > > On May 8, 2014, at 5:02 PM, Paul Moore wrote: > > > > > Or > > > maybe we have to accept that some developers have sound reasons for > >

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 8, 2014, at 5:22 PM, Donald Stufft wrote: >> Socially, this change does not seem to be having the effect of >> persuading more package developers to host on PyPI. The stick doesn't >> appear to have worked, maybe we should be trying to find a carrot? > > Do

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 12:34 AM, Donald Stufft wrote: > The data has finished processing, it represents a time diff of approximately > one year. The pip release that caused all of this was released about 4-5 > months > ago. Oh I forgot to mention: In order to make the comparison as

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote: > On 08.05.2014 23:22, Donald Stufft wrote: >> >>> On a personal note, I'm uncomfortable with the way this change is >>> perceived as a case of *pip* enforcing a behaviour that the pip >>> developers

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 5:01 AM, Paul Moore wrote: > On 9 May 2014 05:34, Donald Stufft wrote: >> On May 8, 2014, at 5:22 PM, Donald Stufft wrote: >> >>>> Socially, this change does not seem to be having the effect of >>>> persuading more package develo

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 7:55 AM, Paul Moore wrote: > On 9 May 2014 12:44, Donald Stufft wrote: >> We still wouldn't be forcing anyone to upload things to PyPI. We are, >> however, >> discouraging people from not hosting on PyPI and providing incentives to >> doin

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 8:21 AM, Paul Moore wrote: > On 9 May 2014 13:06, Donald Stufft wrote: >>>> I think it's important to point out that one of the driving factors that >>>> caused >>>> me to finally push for changes and what lead to PEP438 b

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote: > On 09.05.2014 13:44, Donald Stufft wrote: >> >> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote: >>> Donald: I don't think anyone is arguing that hosting packages on >>> PyPI is a bad thing and PyP

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

easier for me to write PEPs and to update ensurepip. If they’re going to be used as an excuse to attempt to censor me then I’d rather not have them as I generally always speak my mind and I won’t stop doing so. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F0

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 1:28 PM, R. David Murray wrote: > On Fri, 09 May 2014 11:39:02 -0400, Donald Stufft wrote: >> >> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote: >>> On 09.05.2014 13:44, Donald Stufft wrote: >>>> On May 9, 2014, at 4:12 AM, M.-A. Lembu

Re: [Python-Dev] pip: cdecimal an externally hosted file and may be unreliable [sic]

On May 9, 2014, at 4:20 PM, Terry Reedy wrote: > On 5/9/2014 2:12 PM, Donald Stufft wrote: >> >> On May 9, 2014, at 1:28 PM, R. David Murray wrote: > >>> I don't understand this. Why it is our responsibility to provide a >>> free service for a larg

Re: [Python-Dev] [Python-checkins] cpython: Remove the redundant and poorly worded warning message.

a potentially security sensitive module in a cryptographic > context. > I completely agree with Alex, Antoine, and Nick here. I’m both an experienced Python programmer and someone who is generally aware of the security implications of various parts of software. However I appreciate

Re: [Python-Dev] python process creation overhead

te involves invoking (multiple) python processes. This has historically be really slow (~30 minutes to run ~200 tests of that type). We've been able to get the wall clock run time down by parallelizing these but the sequential time is still really slow. - Donald Stufft PGP: 0x6

Re: [Python-Dev] python process creation overhead

200 test in 30 minutes is 9 *seconds* per test -- the Python > startup time is only a tiny fraction of that (20-40 *milliseconds*). > > > On Sat, May 10, 2014 at 3:33 PM, Donald Stufft wrote: > > On May 10, 2014, at 5:46 PM, Victor Stinner wrote: > >> Le 10 mai

Re: [Python-Dev] Python 2.7.7 and PEP 466

bugs being ironed out so it was punted until 2.7.8 (http://bugs.python.org/issue21305) And that was everything from PEP 466. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Des

Re: [Python-Dev] Python 2.7.7 and PEP 466

rom Red Hat or other > distros? > > > On Sun, May 18, 2014 at 7:02 PM, Donald Stufft wrote: > > On May 18, 2014, at 9:53 PM, Guido van Rossum wrote: > >> On Sun, May 18, 2014 at 5:49 PM, Benjamin Peterson >> wrote: >> Greetings Python users, >> P

Re: [Python-Dev] Internal representation of strings and Micropython

I think UTF8 is the best option. > On Jun 3, 2014, at 9:17 PM, Steven D'Aprano wrote: > > There is a discussion over at MicroPython about the internal > representation of Unicode strings. Micropython is aimed at embedded > devices, and so minimizing memory use is important, possibly even > m

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Jun 6, 2014, at 11:41 AM, Steve Dower wrote: > words +1 from me. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGM

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

e minor version > is not A Thing. Why? I mean even if it’s the same thing as 2.7 just with an updated compiler that seems like a better answer than having to deal with 2.7.whatever suddenly breaking all C exts. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Jun 6, 2014, at 3:09 PM, Brian Curtin wrote: > On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft wrote: >> >> On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote: >> >>> On Fri, Jun 6, 2014 at 10:56 PM, wrote: >>>> On Fri, Jun 06, 2014 at 10:49:24PM +

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Jun 6, 2014, at 3:33 PM, Chris Angelico wrote: > On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft wrote: >> Is it really any difference in maintenance if you just stop applying updates >> to >> 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a new compiler then >

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io How are packaging tools supposed to cope with this? AFAIK there is nothing in most of them to deal with a X.Y.Z release suddenly dealing with a different com

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

updated binaries at all. > > Regards, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > Python-Dev mailing list > Python-Dev@python.org > htt

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Jun 7, 2014, at 12:58 AM, Nick Coghlan wrote: > On 7 June 2014 14:47, Donald Stufft wrote: >> On Jun 7, 2014, at 12:41 AM, Nick Coghlan wrote: >>> >>> Words like "just", or "simple", or "easy" really have no place being >>

Re: [Python-Dev] Servicing pypi.python.org

> On Oct 17, 2018, at 8:32 PM, Facundo Batista wrote: > > tl;dr: can we have a (semi)permanent redirect from pypi.python.org > to pypi.org ? This already exists: $ curl -I https://pypi.python.org/project/Twisted/json HTTP/2 301 server: Varnish ret

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On Tuesday, February 19, 2013 at 3:25 PM, Paul Moore wrote: > On 19 February 2013 13:40, Nick Coghlan (mailto:ncogh...@gmail.com)> wrote: > > > If a tools wants to support metadata 2.0, it has to support all > > > the complicated stuff as well, i.e. handle the requires fields, > > > the environmen

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On Tuesday, February 19, 2013 at 6:16 PM, Daniel Holth wrote: > Sorry, Chris must have meant http://hg.python.org/distlib/ . I was struggling > to imagine a world where that is more visible than something on bitbucket. > Half the comments have been about putting something in stdlib right away, >

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote: > On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote: > > Sorry, Chris must have meant http://hg.python.org/distlib/ . I was > > struggling to imagine a world where that is more visible than something on

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote: > > It's not a distributed DoS issue, it's a severe DoS vulnerabilities. A > > single 1 kB XML document can kill virtually any machine, even servers > > with more than hundred GB RAM. > > > > > Assuming an attacker can inject arbi

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Wednesday, February 20, 2013 at 6:23 PM, Christian Heimes wrote: > We can add a function to the XML package tree that enables all restrictions: > > * limit expansion depths of nested entities > * limit total amount of expanded chars > * disable external entity expansion > * optionally force exp

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Wednesday, February 20, 2013 at 6:22 PM, Antoine Pitrou wrote: > On Wed, 20 Feb 2013 18:21:22 -0500 > Donald Stufft mailto:donald.stu...@gmail.com)> > wrote: > > On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote: > > > > It's not a distr

Re: [Python-Dev] cffi in stdlib

A big +1 from me for cffi in the stdlib it's a great library. I just recently started using it to make bindings to a C library. I looked at the ctypes library, but haven't actually used it, because the docs confused me but with cffi I was able to get somewhere just by a liberal use of copy/paste f

Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

On Tuesday, March 5, 2013 at 2:02 AM, Lennart Regebro wrote: > On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins > mailto:robe...@robertcollins.net)> wrote: > > So that is interesting, but its not sufficient to meet the automation > > need Barry is calling out, unless all test suites can be run by > >

Re: [Python-Dev] built-in Python test runner

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Barry Warsaw wrote: > On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote: > >> Doesn't setuptools/distribute already have a setup.py test command? >> That seems like the easiest way forward? > > Yes, and in theory it c

Re: [Python-Dev] cpython (2.7): Issue 17538: Document XML vulnerabilties

___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

> Steven > _______ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372D

[Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

m certificate store if possible, and if that doesn't work falling back to the bundled certificates. That way the various Linux distros can easily have their copies of Python depend soley on their built in certs, but Windows, OSX, Source compiles etc will all still have a fallback value.

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 1:58 AM, Benjamin Peterson wrote: > 2013/6/2 Donald Stufft : >> As of right now, as far as I can tell, Python does not validate HTTPS >> certificates by default. As far as I can tell this is because there is no >> guaranteed certificates available. >

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

/donald%40stufft.io Tracking the Mozilla store isn't difficult. New additions can be ignored for currently released Pythons so we'd just need to watch them for blacklisting certs and roll that into a security update. - Donald Stufft PGP: 0x6E3CBCE93372DC

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote: > On 06/03/2013 09:43 AM, Donald Stufft wrote: >> On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote: >>> >>> The problem with a "slightly outdated" CA store is that it can be a >>> security risk. >

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 12:36 PM, Barry Warsaw wrote: > On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote: > >> So I would like to propose that CPython adopt the Mozilla SSL certificate >> list and include it in core, and switch over the API's so that they verify >> H

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 12:52 PM, Barry Warsaw wrote: > On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote: > >> That's fine with me too. My only reason for wanting to use the system certs >> first is so if someone has modified their system certs (say to include a >>

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

t, they won't need to bundle their own certs and ubuntu/debian can just modify the one location instead of needing to modify it for every package that does it. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 1:07 PM, Barry Warsaw wrote: > On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote: > >> I'd actually prefer for Linux to not use the bundled certs when installed >> from a package manager because it should use the system certs, but people >> can&

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

thon-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald%40stufft.io What about OSX? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

t; > Regards > > Antoine. > > > ___________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald%40stuff

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

have a *very* good story for (legitimate) sites which do cease to work. > > Paul. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailm

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 5:51 PM, Antoine Pitrou wrote: > On Mon, 3 Jun 2013 17:47:31 -0400 > Donald Stufft wrote: >> >> On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote: >> >>> On Mon, 3 Jun 2013 22:31:40 +0100 >>> Paul Moore wrote: >>>>

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On Jun 3, 2013, at 6:01 PM, Paul Moore wrote: > > On 3 June 2013 22:46, Donald Stufft wrote: >> Also, we should consider the issue for application users. Suppose I'm using >> a Python application that downloads something from the web. I upgrade to >> 3.4, and

Re: [Python-Dev] PyPI upload error

mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald%40stufft.io This is probably more appropriate for distutils-sig, but does it happen every time? or did it just happen once

Re: [Python-Dev] Clean way in python to test for None, empty, scalar, and list/ndarray? A prayer to the gods of Python

I never want to iterate, but I love slice syntax and indexing. Don't think you can have that w/o being able to loop over it can you? Maybe I'm just thinking slow since I just woke up. On Jun 15, 2013, at 8:53 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 06/

Re: [Python-Dev] backported Enum

onald%40stufft.io I claimed backport.enum, but you're welcome to the name. I was going to try and backport this PEP under that name anyways. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signe

Re: [Python-Dev] backported Enum

On Jun 15, 2013, at 10:45 PM, Ben Finney wrote: > Ethan Furman writes: > >> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back >> to 2.4 in the 2.x series. >> >> I would like to put this on PyPI, but the `enum` name is already >> taken. > > I have for a long time approved

Re: [Python-Dev] backported Enum

On Jun 16, 2013, at 1:52 AM, Ben Finney wrote: > Donald Stufft writes: > >> On Jun 15, 2013, at 10:45 PM, Ben Finney wrote: >>> Is there anything I can do to keep the ‘enum’ package online for >>> continuity but make it clear, to automated tools, that this is &g

Re: [Python-Dev] When to remove deprecated stuff

thoroughly with the >> new version before upgrading. >> >> Petri > ___________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: &g

Re: [Python-Dev] Offtopic: OpenID Providers

leg Broytmanhttp://phdru.name/p...@phdru.name > Programmers don't die, they just GOSUB without RETURN. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev >

Re: [Python-Dev] Offtopic: OpenID Providers

On Sep 5, 2013, at 2:25 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft > wrote: >> >> On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote: >>> I used to use myOpenID and became my own provider using poit[1]. >>> These d

Re: [Python-Dev] Offtopic: OpenID Providers

On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote: > On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > wrote: >> Persona is the logical successor to OpenID. > > OpenID lived a short life and died a quiet death. I'm afraid Persona > wouldn't live even t

Re: [Python-Dev] Offtopic: OpenID Providers

ized, and free systems like OpenID and Persona. > > -Barry > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io --

Re: [Python-Dev] Offtopic: OpenID Providers

mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCF

Re: [Python-Dev] Offtopic: OpenID Providers

the news a lot lately :) If I recall Persona doesn't leak this data like OpenID does, but perhaps Dan can speak to that better than I can. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed

Re: [Python-Dev] Offtopic: OpenID Providers

__ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A92

Re: [Python-Dev] Offtopic: OpenID Providers

On Sep 6, 2013, at 3:34 PM, "R. David Murray" wrote: > On Fri, 06 Sep 2013 15:17:12 -0400, Donald Stufft wrote: >> On Sep 6, 2013, at 3:11 PM, "R. David Murray" wrote: >> >>> IMO, single signon is overrated. Especially if one prefers not to

Re: [Python-Dev] Offtopic: OpenID Providers

On Sep 10, 2013, at 11:08 AM, Guido van Rossum wrote: > Why do several posts in this thread have an Unsubscribe link that tries to > unsubscribe me from the list? (I saw one by Glen, and another one by Donald > Stufft.) > > (Come to think of it, what's the point of hav

Re: [Python-Dev] PEP 453: Explicit bootstrapping of pip

ng list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA s

[Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

n.org/dev/peps/pep-0439/ References == .. [#ubuntu] `Ubuntu <http://www.ubuntu.com/>` .. [#debian] `Debian <http://www.debian.org>` .. [#fedora] `Fedora <https://fedoraproject.org/>` .. [#homebrew] `Homebrew <http://brew.sh/>` .. [#conda] `Conda <http://www.conti

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

On Sep 19, 2013, at 9:27 AM, Donald Stufft wrote: > We've updated PEP453 based on some of the early feedback we've gotten from > -dev and Martin. > > Major changes: > > * Removal of the option to fetch pip from PyPI in order not to modify the > trust

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

On Sep 19, 2013, at 9:36 AM, Paul Tagliamonte wrote: > On Thu, Sep 19, 2013 at 09:27:24AM -0400, Donald Stufft wrote: >> Rationale >> = >> >> Currently, on systems without a platform package manager and repository, >> installing a third-party Python

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

On Sep 19, 2013, at 9:43 AM, Paul Moore wrote: > On 19 September 2013 14:27, Donald Stufft wrote: >> Major changes: >> >> * Removal of the option to fetch pip from PyPI in order not to modify the >> trust model of the Python installers >> * Consequently re

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

On Sep 19, 2013, at 9:50 AM, Antoine Pitrou wrote: > Le Thu, 19 Sep 2013 09:27:24 -0400, > Donald Stufft a écrit : >> We've updated PEP453 based on some of the early feedback we've gotten >> from -dev and Martin. >> >> Major changes: >> >&g

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

y for new users, so the ideal method is to ensure it's always installed but it'd be totally OK to do what Nick suggested as that still at leasts lets pypi packages to simply document installing as ``pip install `` and if it's not installed by default on Debian they'll get a

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

he separate pip package when a user executes ``pip`` without +it being installed. Systems that choose this option should ensure that +the ``pyvenv`` command still installs pip into the virtual environment +by default. * Do not remove the bundled copy of pip. --------- Do

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

need to be done inside the installers (mostly running the command). - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

ully MvL or someone can do the same with the Windows installer. I'm not sure what needs done outside of the up front work, do I just propose changes to PEP 101? Do I make a whole new PEP? Is there more than just updating PEP 101? > > -- > Ned Deily, > n...@acm.org > > ___

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 23, 2013, at 8:12 PM, Donald Stufft wrote: >> >> >>> A common source of Python installations are through downstream distributors >>> such as the various Linux Distributions [#ubuntu]_ [#debian]_ [#fedora]_, >>> OSX >>> package manager

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

happy to defer to > Martin's judgement on this. After your concern was raised I went ahead and emailed VanL. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed w

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

ortant data point, especially given how long 2.7.LASTEVER is going to be relevant to end users. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 25, 2013, at 5:51 PM, Barry Warsaw wrote: > On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote: > >> I think it should be placed in the source tree for the stable releases. The >> reasoning is that 2.7 is going to stick around for a long time. Immediately >> this

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

Lives > Better. Because with PEP453 you can just ``pip install enum34`` it :) --------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail _

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

e installers) would break someones use any other module? If they don't import it (which the vast bulk of people won't directly, nor at all during the operation of their applications) how does it's existence on the file system risk a breakage to their system? - Donald

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

ls a pip and apt-get playing nicely is on my stack of PEPs to do) ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

Ideally people won't be typing either of them because it'll be installed automatically. They might in some cases (accidentally uninstalled pip?) I agree that it seems there is paranoia going on here and that the risk is low and making it just be a special cased new feature is ok. However the poi

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 26, 2013, at 10:28 AM, Antoine Pitrou wrote: > Le Thu, 26 Sep 2013 10:22:55 -0400, > Donald Stufft a écrit : >> Ideally people won't be typing either of them because it'll be >> installed automatically. They might in some cases (accidentally >> unin

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

able to find > vcvarsall.bat" message and then gone off to find a suitable binary download. Going forward Wheels are binary packages that pip can install. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Descripti

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

tever they are trying to do with all of their libraries are ported to Python3. I still think Python 2.7 is a better target for new users because if you're using Python 3.x theirs a high chance you'll need to port a library or two still. - Donald Stufft PGP: 0x6E3CBC

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

features' policy. The optional installation of pip is not a change to Python > itself. This sounds like a really bad idea to me. You're going to end up with a different stdlib not only by minor release, but by if they installed through an installer or not. -

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 27, 2013, at 4:09 PM, Terry Reedy wrote: > On 9/27/2013 3:10 PM, Donald Stufft wrote: >> >> On Sep 27, 2013, at 2:50 PM, Terry Reedy wrote: >> >>> I add: for 2.7/3.3, there is consequently no need for _ensurepip to be in >>> /Lib after installa

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On Sep 27, 2013, at 9:20 PM, Brett Cannon wrote: > > > > On Fri, Sep 27, 2013 at 5:16 PM, Zachary Ware > wrote: > On Fri, Sep 27, 2013 at 3:29 PM, Donald Stufft wrote: > > > > > > > If it lives in the source tree how are you going to provent it from

<    1   2   3   4   5   >