Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

should not be wasting our precious time on building and > maintaining our own tools or administering the servers on which they run. And > historically we've not done a great job on maintenance and administration. > > Of course it's fun to make tools in Python, and to see th

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

t line is already crossed with other code things already being on github) that’s fine with me. Or I can expand the scope if people think that makes more sense in the PEP too. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ P

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

r just because the other group hasn’t had a public and inflammatory event. > > Not everyone is suited to demonstrate in the streets, but it shouldn't be > that hard to not use a company with > acknowledged bad practices. > > -- > ~Ethan~ > > ___

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

hes of incoming PEPs he’s seen that a lot of the PEPs are being written on Github using git. I think it’s fair to say that those people would prefer PRs on Github over using Bitbucket as well since they were choosing Github over Bitbucket when there was no incentive to do so. --- Donald Stufft PGP:

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 3:26 PM, Brett Cannon wrote: > > > > On Sun Nov 30 2014 at 2:33:35 PM Donald Stufft <mailto:don...@stufft.io>> wrote: > >> On Nov 30, 2014, at 2:19 PM, Brett Cannon > <mailto:br...@python.org>> wrote: >> >> All

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 7:17 PM, Ben Finney wrote: > > Donald Stufft writes: > >> I have never heard of git losing history. > > In my experience talking with Git users about this problem, that depends > on a very narrow definition of “losing history”. > &g

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 7:43 PM, Ben Finney wrote: > > Donald Stufft writes: > >> It’s not lost, [… a long, presumably-accurate discourse of the many >> conditions that must be met before …] you can restore it. > > This isn't the place to discuss the details

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 8:11 PM, Pierre-Yves David > wrote: > > > > On 11/30/2014 08:45 AM, Donald Stufft wrote: >> I don’t make branches in Mercurial because >> i’m afraid I’m going to push a permanent branch to hg.python.org >> <http://hg.python.org>

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

nstead of a .patch from from Roundup. This could allow non-committers to use git if they want, including PRs but without moving things around. The obvious cost is that since the committer side of things is still using the existing tooling there’s no “Merge button” or the other committer benefi

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 8:41 PM, Eric Snow wrote: > > On Sun, Nov 30, 2014 at 6:25 PM, Donald Stufft wrote: >> The technical benefits mostly come from Github generally being a higher >> quality product than it’s competitors, both FOSS and not. > > Here's a solut

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Nov 30, 2014, at 10:08 PM, Pierre-Yves David > wrote: > > > > On 11/29/2014 06:01 PM, Donald Stufft wrote: >> The reason the PEP primarily focuses on the popularity of the the tool is >> because as you mentioned, issues like poor documentation, bad suppor

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

.org/mailman/options/python-dev/donald%40stufft.io Git uses the idea of small individual commands that do small things, so you can write your own commands that work on text streams to extend git and you can even write those in Python. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BC

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

points and not deal-breakers. This sounds like a pretty reasonable attitude to take towards this. If we’re going to be experimenting/talking things over, should I withdraw my PEP? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA __

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

include code reviews in the matrix of what tools we’re going to use then yea? Like Github/Bitbucket/etc have review built in. Other tools like Phabricator do as well but are self hosted instead. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA __

Re: [Python-Dev] My thinking about the development process

> On Dec 5, 2014, at 3:04 PM, Brett Cannon wrote: > This looks like a pretty good write up, seems to pretty fairly evaluate the various sides and the various concerns. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 337

Re: [Python-Dev] Python 2/3 porting HOWTO has been updated

> 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 Do we need to update it? Can it

Re: [Python-Dev] My thinking about the development process

t; > In other words, it seems like the key to improving the productivity of > our CPython patch workflow is to improve the productivity of the patch > workflow for our key workflow resource, bugs.python.org. > > --David > ___ > Pytho

Re: [Python-Dev] My thinking about the development process

> On Dec 6, 2014, at 8:45 AM, Brett Cannon wrote: > > > > On Fri Dec 05 2014 at 3:24:38 PM Donald Stufft <mailto:don...@stufft.io>> wrote: > >> On Dec 5, 2014, at 3:04 PM, Brett Cannon > <mailto:bcan...@gmail.com>> wrote: >> > >

Re: [Python-Dev] My thinking about the development process

these on a cloud provider assuming that their licenses allow that. The other solution would work easier with our current buildbot fleet since you’d just tell it to run some tests but you’d wait until a “trusted” person gave the OK before you did that. A likely solution is to use a pre-merge t

Re: [Python-Dev] My thinking about the development process

> On Dec 6, 2014, at 10:26 AM, Nick Coghlan wrote: > > On 7 December 2014 at 01:07, Donald Stufft wrote: >> A likely solution is to use a pre-merge test runner for the systems that we >> can isolate which will give a decent indication if the tests are going to >

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

moin/2.x-vs-3.x-survey> Just going to say http://d.stufft.io/image/0z1841112o0C <http://d.stufft.io/image/0z1841112o0C> is a hard question to answer, since most code I write is both. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _

Re: [Python-Dev] My thinking about the development process

so I can read them before > PyCon and have informed discussions while I'm there. I will then plan to make > a final decision by May 1 so that we can try to have the changes ready for > Python 3.6 development (currently scheduled for Sep 2015). Is it OK to adapt my current PEP or shoul

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

#x27;s hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010. -

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

> On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote: > >> >> On Dec 12, 2014, at 11:55 PM, Steven D'Aprano wrote: >> >> On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote: >>> So, I'm more than aware of how to write Python 2/3 co

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

> On Dec 13, 2014, at 12:40 AM, Chris Angelico wrote: > > On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft wrote: >> So that's basically it, lowest common demoniator programming where it's hard >> to >> look at the future and see anything but the same (or

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

> On Dec 13, 2014, at 10:17 AM, Barry Warsaw wrote: > > On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote: > >> For what it’s worth, I almost exclusively write 2/3 compatible code (and >> that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so >&

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

gt; > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar..

Re: [Python-Dev] New Windows installer for Python 3.5

d ask. Depending on the answer above, does it make sense to sign the generic .exe (does that even work if we rename it?) which will get used for anything that uses entry points on Windows? Is there any plan to backport this to 2.7 (presumably after some experience is had with it in 3.5)? ---

Re: [Python-Dev] New Windows installer for Python 3.5

wrappers use whatever version they were installs against? Or do you mean the “installed” version might be 3.5 for ``pip.exe`` even though there’s a 3.5.1 for ``pip.exe`` on the PATH? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _

Re: [Python-Dev] My thinking about the development process

nt and helpful. :) Ah oops, I forgot to review that. *goes to do so now*. --- 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 Unsubsc

Re: [Python-Dev] Overriding stdlib http package

the default order of sys.path. --- 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/option

[Python-Dev] Possible "REMOTE HOST IDENTIFICATION HAS CHANGED!" Error.

RSA) $ ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub 256 1d:02:d1:d2:7b:a1:cb:e0:51:65:25:d7:19:dd:4e:74 /etc/ssh/ssh_host_ed25519_key.pub (ED25519) Sorry for any inconvience this causes! --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _

Re: [Python-Dev] Overriding stdlib http package

> On Jan 24, 2015, at 2:57 AM, Nick Coghlan wrote: > > On 15 January 2015 at 07:35, Donald Stufft wrote: >> >> On Jan 14, 2015, at 4:19 PM, Brett Cannon wrote: >> >> But as Guido pointed out, we _like_ it being difficult to do because we >> don't

Re: [Python-Dev] Overriding stdlib http package

> On Jan 24, 2015, at 10:17 AM, Donald Stufft wrote: > > Or you have things like pdb++ which needs to replace the pdb import > because a lot of tools only have a flag like —pdb and do not provide > a way to switch it to a different import. The sys.path ordering means > th

Re: [Python-Dev] Workflow PEP proposals are now closed

481 > <https://www.python.org/dev/peps/pep-0481/> from Donald Stufft that proposes > using GitHub. > > At this point I expect final PEPs by PyCon US so I can try and make a > decision by May 1. Longer still is to hopefully have whatever solution we > choose in pla

Re: [Python-Dev] (no subject)

7;: 1}, y=2, **{'z': 3}) I feel like not only does this genericize way better but it limits the impact and new syntax being added to Python and is a ton more readable. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA __

Re: [Python-Dev] (no subject)

bate and it was decided that duplicate keyword arguments > would remain an error (for now at least). If you want to merge the > dictionaries with overriding, then you can still do: > > function(**{**kw_arguments, **more_arguments}) > > because **-unpacking in dicts overrides as y

Re: [Python-Dev] (no subject)

> On Feb 9, 2015, at 8:34 PM, Neil Girdhar wrote: > > > > On Mon, Feb 9, 2015 at 7:53 PM, Donald Stufft <mailto:don...@stufft.io>> wrote: > >> On Feb 9, 2015, at 7:29 PM, Neil Girdhar > <mailto:mistersh...@gmail.com>> wrote: >> >>

Re: [Python-Dev] (no subject)

> On Feb 10, 2015, at 12:55 AM, Greg Ewing wrote: > > Donald Stufft wrote: >> However [*item for item in ranges] is mapped more to something like this: >> result = [] >> for item in iterable: >>result.extend(*item) > > Actually it would be >

Re: [Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)

whatever it’s called) entrypoints and then give Python something like -m, but which executes a specific entry point name instead of a module name (or maybe -m can fall back to looking at entry points? I don’t know). I’ve given this like… 30s worth of thought, but maybe: pip i

Re: [Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)

> On Mar 9, 2015, at 7:11 PM, Nick Coghlan wrote: > > > On 10 Mar 2015 02:37, "Donald Stufft" <mailto:don...@stufft.io>> wrote: > > > > > > I'm okay with this. Installing for all users is really something that > > >

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

_ > 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 I’ve long wished that the OS had it’s own virtual environment. A lot of problems se

Re: [Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

> On Mar 21, 2015, at 7:52 AM, Nick Coghlan wrote: > > On 19 March 2015 at 07:51, Donald Stufft wrote: >> I’ve long wished that the OS had it’s own virtual environment. A lot of >> problems >> seems to come from trying to cram the things the OS wants with the things

Re: [Python-Dev] some minor questions about pep8

rs, > -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 --- Donald Stufft PGP: 7C6B

Re: [Python-Dev] some minor questions about pep8

> On Mar 21, 2015, at 5:17 PM, MRAB wrote: > > On 2015-03-21 21:00, Donald Stufft wrote: >> >>> On Mar 21, 2015, at 4:53 PM, Barry Warsaw wrote: >>> >>> On Mar 20, 2015, at 08:53 PM, Guido van Rossum wrote: >>> >>>> FWIW, I t

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

ww.egenix.com/ >>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ >> ___

[Python-Dev] Python 3.x Adoption for PyPI and PyPI Download Numbers

ive) server that I have to use to crunch the numbers so if there's anything anyone else wants to see before I shut it down, speak up soon. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___

Re: [Python-Dev] [Distutils] Python 3.x Adoption for PyPI and PyPI Download Numbers

> On Apr 21, 2015, at 3:15 PM, Toshio Kuratomi wrote: > > On Tue, Apr 21, 2015 at 01:54:55PM -0400, Donald Stufft wrote: >> >> Anyways, I'll have access to the data set for another day or two before I >> shut down the (expensive) server that I have to use

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.5.0a4 is now available

g *really* useful. > Paul Is this version statically linked by any chance? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing li

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.5.0a4 is now available

> On Apr 21, 2015, at 7:18 PM, Steve Dower wrote: > > Donald Stufft wrote: >> Is this version statically linked by any chance? > > No, there's no change to the compilation process, so you can get exactly the > same result by using the regular installer and copyi

Re: [Python-Dev] Python 3.x Adoption for PyPI and PyPI Download Numbers

> On Apr 21, 2015, at 11:35 PM, Gregory P. Smith wrote: > > > > On Tue, Apr 21, 2015 at 10:55 AM Donald Stufft <mailto:don...@stufft.io>> wrote: > Just thought I'd share this since it shows how what people are using to > download things from PyPI

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

said, since it's not being included in Python core and it's only some patch that some downstream's are going to apply I also don't really care that much because it's not going to effect me and if it turns out to be a bad idea and a footgun like I think it is, then the blame can

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

> On May 11, 2015, at 6:47 AM, Nick Coghlan wrote: > > On 11 May 2015 at 20:23, Donald Stufft wrote: >> On May 11, 2015, at 6:15 AM, Nick Coghlan wrote: >>> We made the decision when PEP 476 was accepted that this change turned >>> a silent security failure in

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

cations do that. --- Donald Stufft PGP: 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/mailman/listinfo/python-

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

gt;> On 12.05.2015 12:04, Donald Stufft wrote: >> >>> On May 12, 2015, at 3:57 AM, M.-A. Lemburg wrote: >>> >>> In a user based installation (which most applications shipping >>> their own Python installation are), you can always do this >>>

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: > > On 12 May 2015 at 21:09, Donald Stufft wrote: >> If you control the app you don't need to do that. All relevant api accept >> the context parameter. The shims are only useful when you don't control the &

Re: [Python-Dev] PYTHONHTTPSVERIFY env var

> On May 12, 2015, at 7:40 AM, Nick Coghlan wrote: > > On 12 May 2015 at 21:21, Donald Stufft wrote: >> >>> On May 12, 2015, at 7:17 AM, Nick Coghlan wrote: >>> >>> On 12 May 2015 at 21:09, Donald Stufft wrote: >>>> If you control the

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] 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] 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] 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] 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] 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] Preserving the definition order of class namespaces.

io I’m in favor of releasing 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

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

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] 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] 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] 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)

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)

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

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] 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] 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] 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)

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

> 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

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

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

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

<    1   2   3   4   5   >