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

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 >

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. > >

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

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

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

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

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

> On Jun 25, 2017, at 5:39 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 25 June 2017 at 18:31, Donald Stufft <don...@stufft.io> 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 unch

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

emote 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

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

ws file is useful, we also let you add a empty news file marked as trivial for the PR authors to indicate that their change doesn’t deserve a news file entry. It has worked well so far and we’ve gotten better news file coverage then we previously had. — 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

> On Jun 9, 2017, at 3:41 PM, Steve Dower <steve.do...@python.org> 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 fetchi

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

n 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 use for the sak

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

s. Neither of those efforts are 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.

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

> On Jun 8, 2017, at 3:57 PM, Steve Dower <steve.do...@python.org> 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 i

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

> On Jun 8, 2017, at 3:37 PM, Donald Stufft <don...@stufft.io> 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 > benef

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

rge two entirely 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 urlretireve supported that

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

s likely going to be single digit %age within the next 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 ___

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

y (we’d apply a small patch to pip’s copy of requests to make it use it, 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

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

> On Jun 2, 2017, at 12:41 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Fri, 2 Jun 2017 12:22:06 -0400 > Donald Stufft <don...@stufft.io> wrote: >> >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also preve

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

> On Jun 2, 2017, at 12:39 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 3 June 2017 at 02:22, Donald Stufft <don...@stufft.io> wrote: >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on

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

th for C extensions, it also prevents upgrading 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 thou

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

> On Jun 1, 2017, at 3:57 PM, Donald Stufft <don...@stufft.io> 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

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

good about upgrading 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

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

Since we’re still 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.

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

Paul > > > > -- > Giampaolo - http://grodola.blogspot.com <http://grodola.blogspot.com/> > > ___ > Distutils-SIG maillist - distutils-...@python.org > <mailto:distutils-...@python.org> > https://mail

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

u can’t wrap a socket and then 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://ma

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

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 <p.f.mo...@gmail.com> wrote: > > On 16 June 2016 at 12:34, Donald Stufft <don...@stufft.io> wrote: >> [1] I don’t think using os.urandom is incorrect to use for security sensitive >>applications and I think it’s

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 <ba...@python.org> 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 does

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

with the same general 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 lis

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

in whatever you write 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/optio

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 <gu...@python.org> wrote: > > On Sat, Jun 11, 2016 at 1:48 PM, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > >> On Jun 11, 2016, at 3:40 PM, Guido van Rossum <gu...@pytho

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

ally secure random bytes. — 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?

been reverted to 3.4 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/p

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 <gu...@python.org> wrote: > > On Sat, Jun 11, 2016 at 11:30 AM, Donald Stufft <don...@stufft.io > <mailto:don...@stufft.io>> wrote: > >> On Jun 11, 2016, at 1:39 PM, Guido van Rossum <gu...@pytho

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

'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.org https

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

t of options by just adding 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/listin

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

le data whereas getrandom(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?

always doing whatever 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/

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

LOCK) on Linux systems where 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/l

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 <don...@stufft.io> 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.

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

low bad 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 <don...@stufft.io &g

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

"code smell" 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

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 <st...@pearwood.info> 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

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

l has been initialized. The concept of “running out of entropy” 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 <st...@pearwood.info> wrote: >> On Thu,

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

properties 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?

m(..., 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 (python.org/~guido <http://python.org/~guido>) — Donald Stufft ___

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

very single 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?

the old API in 99.% of 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 ha

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

e Solaris did in that 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:/

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

out 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 Python script too early. [1] To the best of our ability, given the interfa

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

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

rted OpenSSL versions have SHA3. 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: ht

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

ations in cases where people 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 ma

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

rely on OpenSSL if 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-de

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

a really great hash and a lot of things are starting 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

Re: [Python-Dev] Yearly PyPI breakage

> On May 6, 2016, at 1:11 PM, A.M. Kuchling <a...@amk.ca> 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 implemen

Re: [Python-Dev] Yearly PyPI breakage

'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 would get done. [1] https://mail.python.org/pipermail/distutils-sig/2013-April/020553.html [2] https://groups.google.com/d/msg/pypa-dev/ZjUNk

Re: [Python-Dev] Yearly PyPI breakage

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 of the contact channels that you were offered to try and resolve the issue that you had with a project on PyPI. [1] https://bugs.python.org/is

Re: [Python-Dev] Yearly PyPI breakage

w.python.org/dev/peps/pep-0470/#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

the type. This is only the 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. ---

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

h(...).open(). 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: 0x6E3CBCE933

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

cenarios that you’re actually dealing 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 u

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

__ to return bytes as well 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. -----

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

running 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

Re: [Python-Dev] Defining a path protocol

th.__init__, which would 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). -----

Re: [Python-Dev] More optimisation ideas

> On Jan 31, 2016, at 12:02 PM, Brett Cannon <br...@python.org> 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. --------- Do

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

working > for Red Hat, the 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 d

Re: [Python-Dev] Translate Python language

ords 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: 0x6E3CBCE93372DCFA // 7C6B 7C5D

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

tandard 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 F04F

Re: [Python-Dev] PEP acceptance and SIGs

sed 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] 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] Choosing an official stance towards module deprecation in Python 3

em 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

ther 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.org https:

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

r 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.python.org/

Re: [Python-Dev] provisional status for asyncio

stdlib but I’m not sure how popular that opinion is :)  - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo

Re: [Python-Dev] provisional status for asyncio

it possible. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https

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, 13. We have 2 weeks

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

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. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F

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 wheel, if you install that optional dependency

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

On Aug 7, 2015, at 3:02 AM, Nick Coghlan ncogh...@gmail.com wrote: On 7 August 2015 at 08:50, Robert Collins robe...@robertcollins.net 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

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

On Aug 7, 2015, at 11:13 AM, Chris Barker - NOAA Federal chris.bar...@noaa.gov 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

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

On Aug 6, 2015, at 5:04 AM, Robert Collins robe...@robertcollins.net 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

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

of ensurepip was considered better than minimizing the things we bundled. On the flip side, the thing you lose if you don’t have wheel installed is more like a “nice to have” than something that breaks functionality that most people would consider mandatory in the current landscape. --- Donald

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

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 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 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. Here’s why: * Even on Linux systems Python

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 thing I've seen more than once is that new development happens in Python until

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

. 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 is a very attractive way. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

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

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 BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo

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

you expected? etc etc. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman

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

site-packages in sys.path, so pip can’t upgrade those pre-installed software packages at all.  --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman

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

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: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev

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

within that zip file as well, but that can be done as a library easier than the above three things can. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org

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 modules via zipzimport (ideally without

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 things you need on Windows to be able

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 example, if you're making an application

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

applications. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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

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

it is what it is or release more often. The inbetween is killer. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe

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

more often as well. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA___ 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

  1   2   3   4   5   >