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] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On May 31, 2018, at 10:22 AM, Nick Coghlan wrote: > > On 31 May 2018 at 19:34, Nathaniel Smith > wrote: > On Wed, May 30, 2018, 14:21 Victor Stinner > wrote: > MemoryBIO was the key feature which allowed to implement TLS for the > ProactorE

Re: [Python-Dev] What is the rationale behind source only releases?

> On May 16, 2018, at 1:06 AM, Ben Finney wrote: > >> >> I'd like to know the rationale behind source only releases of cpython. > > Software freedom entails the freedom to modify and build the software. > For that, one needs the source form of the software. > > Portable software should be fea

Re: [Python-Dev] Move ensurepip blobs to external place

From my POV I don’t care where they live, just document how to update them going forward. Sent from my iPhone > On Mar 24, 2018, at 4:50 AM, Serhiy Storchaka wrote: > > Wouldn't be better to put them into a separate repository like Tcl/Tk and > other external binaries for Windows, and downlo

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

> On Nov 19, 2017, at 8:40 AM, Nathaniel Smith wrote: > > We have been using DeprecationWarning for changes where code will > transition from working -> raising an error, and that *is* based on > the Official Recommendation to hide those by default whenever > possible. We've been doing this for

Re: [Python-Dev] Remove typing from the stdlib

> On Nov 6, 2017, at 4:35 AM, Paul Moore wrote: > > 1. Without typing available, some programs using type annotations > won't run. That is, using type annotations (a > test-time/development-time feature) introduces a runtime dependency on > typing, and hence introduces an extra deployment conce

Re: [Python-Dev] Migrate python-dev to Mailman 3?

> On Oct 26, 2017, at 6:19 AM, Antoine Pitrou wrote: > > The pipermail UI isn't perfect (the monthly segregation can be annoying > as you point out), but at least it has a synthetic and easy-to-navigate > tree view. Pipermail is *horrible* and it’s tree view makes things actively harder to read

Re: [Python-Dev] Helping contributors with chores (do we have to?)

> On Jun 25, 2017, at 5:39 PM, Paul Moore wrote: > > On 25 June 2017 at 18:31, Donald Stufft wrote: >> >> I have used it. I don’t use it every day but I’ve never had it fail on me >> unless the contributor has unchecked the flag. I just ``git remote add >> `

Re: [Python-Dev] Helping contributors with chores (do we have to?)

e add `` then checkout their branch, add more commits, and push to their branch. — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] New workflow change: Welcome to blurb

ugh the web UI than either ask for it and > deal with the turnaround time to get the PR submitter to add it. > We’ve had a similar check on pip for awhile now and we’ve had no real complaints. The label to mark a change as not needing a news file is useful, we also let you add a empty n

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 9, 2017, at 3:41 PM, Steve Dower wrote: > > On 09Jun2017 1118, Donald Stufft wrote: >> A ensuressl style module that tries to install an OpenSSL module is actually >> fairly hard to do securely. The fundamental issue being that fetching a file >> securely

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

stop bundling it in our installers under the guise of “we have a newer, better API for handling this, and if you still need 2.7 compatibility, here’s the pip installable libraries you need to install to get it”. [2] Where reasonable means, it’s not sacrificing good things or making things harder to

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

going to be quick or simple tasks, so the work to make them possible can happen while we wait for adoption to naturally grow on 2.7.14. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/p

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 8, 2017, at 3:57 PM, Steve Dower wrote: > > On 08Jun2017 1237, Donald Stufft wrote: >> The basic yak stak here is: >> * PEP 543 should be the future, it is a much much better way of handling TLS >> than our current ssl module is. >> * Cory can’t spen

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 8, 2017, at 3:37 PM, Donald Stufft wrote: > > So basically back porting MemoryBio unlocks two important things for the > health of the Python ecosystem: > > * Allows forward progress on PEP 543, which provides a wealth of great > benefits like using the pla

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

irely different configuration systems? It would require rewriting significant parts of our code that interfaces with HTTP, including the fact that we rely on some additional requests libraries (like cache control) to implement HTTP caching in pip, so unless urlretir

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

ext 6-8 months IIRC. If 2.7.14 follows a similar trajectory, requests can depend on it within like… 2 years? Maybe 3? Likely it will depend on whether 2.7.14 gets into the next Ubuntu LTS or not. — Donald Stufft ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

t, but that’s easy to do with our setup) I think that would be workable. I think that’s a less optimal solution than just accepting PEP 546 which I think is beneficial to the Python ecosystem as a whole, making it easier to port more code onto 3.x (and allowing unlocking 3.x’s capabilities) and wi

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 2, 2017, at 12:41 PM, Antoine Pitrou wrote: > > On Fri, 2 Jun 2017 12:22:06 -0400 > Donald Stufft wrote: >> >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on Windows because having

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 2, 2017, at 12:39 PM, Nick Coghlan wrote: > > On 3 June 2017 at 02:22, Donald Stufft wrote: >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on Windows because having pip import >> PyOpe

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

PyOpenSSL on Windows because having pip import PyOpenSSL locks the .dll, and we can’t delete it or overwrite it until the pip process exits and no longer imports PyOpenSSL. This isn’t a problem on Linux or macOS or the other *nix clients though

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

> On Jun 1, 2017, at 3:57 PM, Donald Stufft wrote: > > Note that on macOS, within the next year macOS users using the system Python > are going to be unable to talk to PyPI anyways (unless Apple does something > here, which I think they will), but in either case, Apple

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

g to 2.7.9 (I think they had the first OS released that supported 2.7.9?). — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

ill at 90% of downloads from PyPI being done using Python 2, that suggests the threshold for Python 3.x is very far away and will extend beyond 2020 (I mean, we’re just *now* finally able to drop support for Python 2.6). In case it’s not obvious, I am very much in support of this PEP. — Donald S

Re: [Python-Dev] [Distutils] pythonhosted.org upload no longer works

; -- > Giampaolo - http://grodola.blogspot.com <http://grodola.blogspot.com/> > > ___ > Distutils-SIG maillist - distutils-...@python.org > <mailto:distutils-...@python.org> > https://mail.python.org/mailman/listinfo/distutils-sig > <https://mail.python.org/mailman/listinfo/distutils-sig> — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] Let's make the SSL module sane

en add certificates after the fact… but I don’t even know if that makes sense to do? — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/option

Re: [Python-Dev] PyPI index deprecation

Dmitry Trofimov jetbrains.com> writes: > > We will be very happy if the functionality of the index is restored at least > for some short period of time: please, give as a couple of weeks. That will > allow us to implement a workaround and provide the fix for the several latest > major versions o

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

> On Jun 16, 2016, at 8:50 AM, Paul Moore wrote: > > On 16 June 2016 at 12:34, Donald Stufft wrote: >> [1] I don’t think using os.urandom is incorrect to use for security sensitive >>applications and I think it’s a losing battle for Python to try and fight >>

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

> On Jun 16, 2016, at 7:07 AM, Barry Warsaw wrote: > > On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote: > >> Regardless of what we document it as, people are going to use os.urandom for >> cryptographic purposes because for everyone who doesn’t keep up on exactly &

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

eneral runtime characteristics of /dev/urandom outside of cases where it’s not safe to actually use /dev/urandom. Frankly, I think it’s a disservice to Python developers to leave in this footgun. — Donald Stufft ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] writing to /dev/*random [was: BDFL ruling request: should we block ...]

into the entropy, but it won’t increase the entropy counter for it. — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 11, 2016, at 5:16 PM, Guido van Rossum wrote: > > On Sat, Jun 11, 2016 at 1:48 PM, Donald Stufft <mailto:don...@stufft.io>> wrote: > >> On Jun 11, 2016, at 3:40 PM, Guido van Rossum > <mailto:gu...@python.org>> wrote: >> >> Yeah, bu

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

d likely be possible to have os.getrandom() with blocking semantics and no FD on all of the most popular platforms we support. If we relax the no FD then FreeBSD and OS X also have /dev/random (or /dev/urandom it’s the same thing) which will ensure that you give cryptographically secure random

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

semantics (well, it will try to use getrandom(GRD_NONBLOCK) but falls back to /dev/urandom if that would have blocked). — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 11, 2016, at 3:40 PM, Guido van Rossum wrote: > > On Sat, Jun 11, 2016 at 11:30 AM, Donald Stufft <mailto:don...@stufft.io>> wrote: > >> On Jun 11, 2016, at 1:39 PM, Guido van Rossum > <mailto:gu...@python.org>> wrote: >> >> Is the

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

latforms, so we've > passed that station. > Sorry, to be more specific I meant the 3.4 behavior, which was open(“/dev/urandom”).read() on *nix and CryptGenRandom on Windows. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

g flags to os.urandom unless we add flags that work for every possible combination of what people may or may not want to. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsub

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

(GRND_NONBLOCK) will EAGAIN. — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

is required to > be as secure as possible. https://bugs.python.org/issue27288 <https://bugs.python.org/issue27288> — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscr

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

ere getrandom() is available. Of course, it’s just an alias for random.SystemRandom, and that is documented as using os.urandom. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsub

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 10, 2016, at 2:55 PM, Donald Stufft wrote: > > So really, out of the recommended solutions you really only have find a way > to interface with the getrandom() function, or just consume /dev/urandom and > hope it’s been initialized. I’d note, this is one of the rea

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

; > I'm not quite sure I understand all of your question, Donald. On Python > 3.4—and by BDFL declaration on 3.5.2—os.urandom() *will not* block, although > it might on 3.5.1. > > On Fri, Jun 10, 2016 at 11:33 AM, Donald Stufft <mailto:don...@stufft.io>>

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

; is fine, but I > kinda hope it exists at all. Do you mean if os.urandom blocked and you wanted to call os.urandom from your boot script? Or if os.urandom doesn’t block and you wanted to ensure you got good random numbers on boot? — Donald Stufft __

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

ding contributing to Python at all, because of this kind of rhetoric. — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

> On Jun 9, 2016, at 1:14 PM, Steven D'Aprano wrote: > > On Thu, Jun 09, 2016 at 12:39:00PM -0400, Donald Stufft wrote: > >> There are three options for what do with os.urandom by default: >> >> * Allow it to silently return data that may or may not be &

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

ropy” doesn’t apply to it. Once it has entropy it’s good to go. > > As for blocking vs returning less random results, I defer to others on that. > > On 9 June 2016 at 18:14, Steven D'Aprano wrote: >> On Thu, Jun 09, 2016 at 12:39:00PM -0400, Donald Stufft wrot

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

ties as well). My opinion is that blocking is slightly better than raising an exception because it matches what other OSs do, but that both blocking and raising an exception is better than silently giving data that may or may not be cryptographically secure. — Donald Stufft _

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

ing why it's so slow. > > Maybe we can put in a warning when getrandom(..., GRND_NONBLOCK) returns > EAGAIN? And then award a prize to people who can make it print that warning. > Maybe we'll find a way to actually test this code. > > -- > --Guido van Rossum (py

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

use, but I'm sure someone can dig up one person somewhere who purposely used this behavior. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.py

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

cases and it's fighting against the entire software ecosystem's suggestion of what to use ("use urandom" is basically a meme at this point). This is like saying that we can't switch to verifying HTTPS by default because a one in a million connection might have different behavi

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

hat issue, it's to use the newer, better, interface to make Linux use the more secure behavior that most (all?) of the other modern OSs have already adopted. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/ma

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

ikely to only ever been hit by OS vendors themselves, who are in the best position to make informed decisions about how to work around the fact the urandom entropy pool hasn't already been initialized rather than expecting every other user to have to try and ensure that they don't start their

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

> On May 28, 2016, at 5:06 PM, Guido van Rossum wrote: > > But you could choose which implementation to use at compile time based > on the autoconf output, right? I think we should follow what hashlib already does. If we want to change the way it works that's fine but these hashes shouldn't be

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

HA3. It still will be needed for as long as it’s possible to build Python without OpenSSL. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

le either don’t have OpenSSL or don’t have a new enough OpenSSL for those implementations. Not having the fallback just makes it more difficult for people to rely on those hash functions. — Donald Stufft ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

I recall, I mean it will use it if OpenSSL is available but otherwise it has internal implementations too. — Donald Stufft ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mai

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

ing to be built on top of it. In particularly I’d like to use this in PyPI and pip- but I can’t unless it’s in the standard library. — Donald Stufft ___ 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/archive%40mail-archive.com

Re: [Python-Dev] Yearly PyPI breakage

> On May 6, 2016, at 1:11 PM, A.M. Kuchling wrote: > > On Thu, May 05, 2016 at 10:31:48PM -0400, Donald Stufft wrote: >> I don't believe we've ever told someone that something can't happen because >> of >> Warehouse, only that *I* won't impl

Re: [Python-Dev] Yearly PyPI breakage

e of Warehouse, only that *I* won't implement something until after Warehouse. That often times means that something won't happen until after Warehouse because of the severe shortage of people with enough time and motivation to work on this stuff but if someone did step up more things wou

Re: [Python-Dev] Yearly PyPI breakage

ith PyPI that we consult the PSF board members, particularly the ones who are lawyers. I do recall that the last time m3-cdecimal came up [1] you (again) brought up issues you had with PyPI in an inappropriate venue and as far as I know, you never actually used any

Re: [Python-Dev] Yearly PyPI breakage

70/#i-can-t-host-my-project-on-pypi-because-of-x-what-should-i-do . - 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] pathlib - current status of discussions

case if you have a singular RichPath object that can represent both bytes and str (which is what DirEntry does, which I agree makes it harder… but that’s already the case with DirEntry.path). However that’s not the case if you have a bRichPath and uRichPath. ----- Donald Stufft PGP:

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

I think it was a mistake to have Path(…).open to be honest and I think the main reason it exists is because open(Path(…)) doesn’t work (yet!). You can’t hang every single thing you might ever want to do to a Path off the path object. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7

Re: [Python-Dev] pathlib - current status of discussions

ng with them is the kind of change that 3.0 made that ended up getting rolled back where it could. - 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] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

as str. The only argument I can think against it is that something like pathlib.Path() would not work with a bytes returning __fspath__, but that’s not any different than what happens if you pass a bytes object directly into pathlib.Path as well. ----- Donald Stufft PGP: 0x6E3CBCE93372

Re: [Python-Dev] Pathlib enhancments - method name only

g on Windows. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

Re: [Python-Dev] Defining a path protocol

mean that if other libraries implemented __fspath__ then you could pass their path objects to pathlib and it would just work (and similarly, if they also called fspath it would enable interoperation between all of the various path libraries). ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C

Re: [Python-Dev] More optimisation ideas

> On Jan 31, 2016, at 12:02 PM, Brett Cannon wrote: > > A lazy importer was added in Python 3.5 Is there any docs on how to actually use the LazyLoader in 3.5? I can’t seem to find any but I don’t really know the import system that well. ----- Donald S

Re: [Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

air is getting thin. Benjamin is familiar with the ssl > module. Or we can follow Alex's advice and ask somebody from the PyCA > group (Donald, Paul, lvh) or requests (Cory) to get some outside > perspective. > Under normal circumstances I'd probably be willing to do it even thoug

Re: [Python-Dev] Translate Python language

tually keywords but are names of > functions defined in the builtins and/or standard library. Those are > not exposed as distinct objects in the AST, but are simply name > lookups. > You might be able to use an encoding to do this. - Donald Stufft PGP: 0x6E3CBCE93372DCF

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

On October 29, 2015 at 2:28:02 PM, Paul Moore (p.f.moore=40gmail.com) wro= te: > On 29 October 2015 at 17:36, Donald Stufft wrote: > > On October 29, 2015 at 1:32:31 PM, Nathaniel Smith (njs=40pobox.com) = wrote: > >> > (I know saying that last part out loud will probably ju

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

the standard library in a sane way though. Like how pdb++ does. This is already possible if you install stuff as .eggs and the world hasn’t burned down, it’s just not easily possible if you don’t install as eggs. ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926

Re: [Python-Dev] PEP acceptance and SIGs

On September 30, 2015 at 9:14:42 PM, Alexander Belopolsky (alexander.belopol...@gmail.com) wrote: > On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote: > > > > I don’t see any requirement to post PEPs to python-dev if they have a > Discussions-To header in PEP 1. >

Re: [Python-Dev] PEP acceptance and SIGs

recently not using PEPs for packaging things that don’t have anything to do with the standard library and moving to a more lightweight process more akin to the Rust RFC process for various reasons). ----- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BC

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

memory might be faulty. The second problem is easier, you can add multiple people to a project, and "Organization/Group" accounts will be something that gets implemented in Warehouse. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3

ave other parts of the standard library depending on them, but #1 wouldn't work fo those anyways. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.

Re: [Python-Dev] Should we use getentropy() for os.urandom()?

d use it or not, but getrandom is basically a better form of /dev/urandom. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.p

Re: [Python-Dev] provisional status for asyncio

On August 28, 2015 at 12:07:48 PM, Victor Stinner (victor.stin...@gmail.com) wrote: > 2015-08-28 18:02 GMT+02:00 Donald Stufft : > > Unless we fix the sys.path ordering to make it possible. > > The problem is the deadline: Python 3.5 final is scheduled for the > September, 1

Re: [Python-Dev] provisional status for asyncio

grade a third-party library than > upgrading the system python. > Unless we fix the sys.path ordering to make it possible. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python

Re: [Python-Dev] provisional status for asyncio

ight, the default sys.path is stdlib > user-packages > site-packages. I would personally prefer it if looked more like user-packages > site-packages > stdlib but I’m not sure how popular that opinion is :)  - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356

Re: [Python-Dev] updating ensurepip to include wheel

On August 16, 2015 at 11:26:08 AM, Steven D'Aprano (st...@pearwood.info) wrote: > On Sun, Aug 16, 2015 at 10:52:00AM -0400, Donald Stufft wrote: > > > > So what is the benefit of including wheel with ensurepip? > > > > pip has an optional dependency on whe

Re: [Python-Dev] updating ensurepip to include wheel

drastically improve installation speeds by caching built artifacts (i.e. ``pip instal lxml`` multiple times only compiles it once). The goal is to get more people getting the benefits of that by default instead of requiring them to know they need to ``pip install wheel`` after the fact. ---

Re: [Python-Dev] updating ensurepip to include wheel

> On Aug 7, 2015, at 11:13 AM, Chris Barker - NOAA Federal > wrote: > >> Please don't add extra pain for purity and >> make sure that ensurepip installs "pip" and >> not "slow pip until you install wheel in the venv". > > > This is a really good point -- other than purity, what is the downsid

Re: [Python-Dev] updating ensurepip to include wheel

> On Aug 7, 2015, at 3:02 AM, Nick Coghlan wrote: > > On 7 August 2015 at 08:50, Robert Collins wrote: >> Certainly the framing of ensurepip as 'this installs pip' is going to >> be confusing and misleading if it doesn't install pip the way >> get-pip.py (or virtualenv) install pip, leading to

Re: [Python-Dev] updating ensurepip to include wheel

> On Aug 6, 2015, at 5:04 AM, Robert Collins wrote: > > Yes: but the logic chain from 'its a bad idea' to 'we don't include > wheel but we do include setuptools' is the bit I'm having a hard time > with. In my opinion, it’s the severity of how crippled their experience is without that particu

Re: [Python-Dev] updating ensurepip to include wheel

ice to have” than something that breaks functionality that most people would consider mandatory in the current landscape. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https:

Re: [Python-Dev] updating ensurepip to include wheel

do not require end users to install it explicitly. That being said, I think the PEP would need to be updated (and possibly a new  PEP?) since we explicitly called out the fact that setuptools would currently be included until pip no longer needed it to be installed seperately. --- Donald Stufft

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

On May 29, 2015 at 2:58:28 AM, Nick Coghlan (ncogh...@gmail.com) wrote: > On 29 May 2015 9:48 am, "Donald Stufft" wrote: > > > > > > > > On May 28, 2015 at 7:40:26 PM, Nick Coghlan (ncogh...@gmail.com) wrote: > > > > > > > > One t

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On May 29, 2015 at 4:37:37 AM, Steven D'Aprano (st...@pearwood.info) wrote: > On Thu, May 28, 2015 at 01:20:06PM -0400, Donald Stufft wrote: > > > I think it’s an issue for all platforms, even when there is a system Python > > that can be used. > > > >

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

;s cffi. > I’m not sure if I’m reading this right or not, but just to be clear, I’ve seen a number of people express the sentiment that they are switching from Python to Go and that the deployment story is one of the reasons. It’s not just people switching from C/C++. --- Donald Stufft PGP: 7C6

Re: [Python-Dev] Keeping competitive with Go (was Re: Computed Goto dispatch for Python 2)

ay be popular for distributing end > user applications, but definitely not for distributing a core OS or a SDK. > Sorry, you didn't yet arrive in distro land ... > > I don’t think anyone is claiming that single file should be the *only* way, just that for a sizable set of people it i

Re: [Python-Dev] Single-file Python executables

v/donald%40stufft.io > The problem is I'm an idiot and did du -h against ``which python``, which of course resolved to the symlink of python that points to python3.4. The real executable on my OSX box is 2.6M (built using pyenv). --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C

Re: [Python-Dev] Computed Goto dispatch for Python 2

of users (and since I work on pip, they tend to come to us with the weirdo problems). Case in point: Python on OS X adds some preinstalled software, but they put this pre-installed software before site-packages in sys.path, so pip can’t upgrade those pre-installed software packages at all.  --- Do

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

thon 2.7 but you want to deploy your app in Python 3? * What if you have Python installed already, but it’s been patched by the place   you got it from and now the behavior is different than what you expected? etc etc. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

whether it will help Python as a whole. It’s also not an either/or proposition, we can both improve our ability to develop under iOS/Android/etc and improve our ability to handle desktop applications. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On May 28, 2015 at 12:01:22 PM, Barry Warsaw (ba...@python.org) wrote: > On May 28, 2015, at 11:39 AM, Donald Stufft wrote: > > >You don’t need a "fully functioning Python" for a single file binary, you > >only need enough to actually run your application. For exa

Re: [Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

On May 28, 2015 at 11:30:37 AM, Steve Dower (steve.do...@microsoft.com) wrote: > Donald Stufft wrote: > > Well Python 3.4.3 binary is 4kb for me, so you'd have that + your 1KB > > Python script + whatever > other pieces you need. > > For contrast, here are the

Re: [Python-Dev] Computed Goto dispatch for Python 2

On May 28, 2015 at 10:55:08 AM, Steve Dower (steve.do...@microsoft.com) wrote: > Donald Stufft wrote: > > I think docker is a pretty crummy answer to Go’s static binaries. What I > > would > > love is for Python to get: > > > > * The ability to import .so module

Re: [Python-Dev] Computed Goto dispatch for Python 2

easily create a single file executable with real, native support from Python by simply compiling Python in that static mode and then appending a zip file containing the standard library and any other distributions we need to the end of it. We’d

Re: [Python-Dev] Preserving the definition order of class namespaces.

not making it available to the 2.x line at all. I think that it would have been better to release it as a 2.8, however that was a hill I felt like dying on personally. Going forward I think we should either stick to the slower release schedule and just say it is what it is or release more often. T

  1   2   3   4   5   >