Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)

t will hopefully be resolved before too long. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https:/

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 1 Sep 2014 16:05, "Nick Coghlan" wrote: > > The final change would be to seed the context factory map > appropriately for the standard library modules where we wanted to keep > the *old* default: > > for modname in ("nntplib", &qu

Re: [Python-Dev] Sad status of Python 3.x buildbots

On 3 Sep 2014 08:15, "Victor Stinner" wrote: > > x86 RHEL 6 3.x: TestReadline.test_init() fails, issue #19884. I don't > have to this platform, I don't know how to fix it. Sorry, I haven't been a very good maintainer for that buildbot (the main reason it never graduated to the "stable" list). If

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 3 Sep 2014 08:18, "Alex Gaynor" wrote: > > Antoine Pitrou pitrou.net> writes: > > > > > And how many people are using Twisted as an HTTPS client? > > (compared to e.g. Python's httplib, and all the third-party libraries > > building on it?) > > > > I don't think anyone could give an honest est

Re: [Python-Dev] Sad status of Python 3.x buildbots

On 3 Sep 2014 09:00, "Brian Curtin" wrote: > > On Tue, Sep 2, 2014 at 5:53 PM, Nick Coghlan wrote: >> >> From a completely different perspective, does anyone have experience with using BuildBot with OpenStack hosted clients? We may be able to take advantage of

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 3 Sep 2014 09:08, "David Reid" wrote: > > Nick Coghlan gmail.com> writes: > > > Creating *new* incompatibilities between Python 2 & Python 3 is a major point > > of concern. > > Clearly this change should be backported to Python2. Proposing to br

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 3 Sep 2014 18:28, "Cory Benfield" wrote: > This is definitely true, and this change is both. The only question > that matters is whether we believe we're doing users a service by > breaking their code. I'd argue, along with Glyph, Alex and Donald, > that we are. I've been on the losing side of

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 4 Sep 2014 04:39, "Antoine Pitrou" wrote: > > On Wed, 3 Sep 2014 10:54:55 -0700 > Guido van Rossum wrote: > > > > Let's take the plunge on this issue for the next 2.7 release (3.5 being a > > done deal). > > I'm entirely against this. > > > Yes, some people will find that they have an old scri

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 4 Sep 2014 06:39, "Alex Gaynor" wrote: > > Guido van Rossum python.org> writes: > > > OK, that changes my position for 2.7 (but not for 3.5). I had assumed there > > was a way to disable the cert check by changing one parameter to the > > urlopen() call. (And I had wanted to add that there sho

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

On 1 September 2014 08:00, Nick Coghlan wrote: > Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7 > maintenance release in addition to including it with Python 3.4. > > That part of the proposal proved to be controversial, so we dropped it from > the origin

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 4 September 2014 10:00, Ethan Furman wrote: > On 09/03/2014 04:36 PM, Antoine Pitrou wrote: >> >> On Thu, 4 Sep 2014 09:19:56 +1000 >> Nick Coghlan wrote: >>>> >>>> >>>> Python is routinely updated to bugfix releases by Linux distri

Re: [Python-Dev] Sad status of Python 3.x buildbots

atforms (and provide a reliable build). It sounds like a good idea in principle, but I suspect there would be a lot of devils in those details. That doesn't make it a bad idea, just something that would need a volunteer to investigate further before we could form a real opinion. Cheers, Nick.

Re: [Python-Dev] PEP 477: selected ensurepip backports for Python 2.7

On 4 September 2014 12:21, Benjamin Peterson wrote: > On Wed, Sep 3, 2014, at 17:03, Nick Coghlan wrote: >> On 1 September 2014 08:00, Nick Coghlan wrote: >> > Earlier versions of PEP 453 proposed bootstrapping pip into a Python 2.7 >> > maintenance release in ad

Re: [Python-Dev] Sad status of Python 3.x buildbots

they work, so unless someone is particularly keen and willing to work through all the factors that led to the current setup and propose changes (including at least a rough concept of how ongoing maintenance will work), the status quo wins by default. Cheers, Nick. -- Nick Coghlan | ncogh...@gma

Re: [Python-Dev] Sad status of Python 3.x buildbots

this idea really sits somewhere between infrastructure and python-dev, as Antoine does most of the BuildBot master maintenance). If we could get something like that running, then we might be able to trim the preconfigured buildbot fleet back to just the non-x86 machines. Cheers, Nick. -- Nick Coghlan

Re: [Python-Dev] Sad status of Python 3.x buildbots

What is needed to get that up and running? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://m

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 4 September 2014 22:39, Antoine Pitrou wrote: > On Thu, 4 Sep 2014 13:11:38 +1000 > Nick Coghlan wrote: >> That leaves Python 2.7, and I have to say I'm now persuaded that a >> backport (including any required httplib and urllib features) is the >> right way to

Re: [Python-Dev] cpython (3.4): Issue #22295: Adopt 'python -m pip' as the preferred invocation

On 6 Sep 2014 23:15, "Paul Moore" wrote: > > On 6 September 2014 13:47, Skip Montanaro wrote: > > Based on the comment in the second issue, it doesn't appear this will > > be resolved until 1.7 at the earliest. > > The second issue is specific to setuptools, where we have some very > unpleasant h

Re: [Python-Dev] Sad status of Python 3.x buildbots

e release process. > Then there's the testing bit (it's separate from the python binaries build to insulate the two). It's very similar and I'll post more details when ready. Thanks again! Regards, Nick. > > I hope this helps, > Thnaks > > > > Antonio C

Re: [Python-Dev] Proposed schedule for 3.4.2

er fix the certs, patch the code to cope with them appropriately, or (for the self-signed cert case) configure OpenSSL via environment variables. If dealing with invalid certs is truly necessary, and the code can't be updated either, then I'm OK with the answer being "keep using an

Re: [Python-Dev] Proposed schedule for 3.4.2

On 9 Sep 2014 04:00, "Barry Warsaw" wrote: > > > >This would need to be updated first, once it *did* take such an argument, > >this would be accomplished by: > > > >context = ssl.create_default_context() > >context.verify_mode = CERT_OPTIONACERT_NONE > >context.verify_hostname = False > >urllib.re

Re: [Python-Dev] Proposed schedule for 3.4.2

On 9 Sep 2014 08:20, "Nick Coghlan" wrote: > > > On 9 Sep 2014 04:00, "Barry Warsaw" wrote: > > > > > >This would need to be updated first, once it *did* take such an argument, > > >this would be accomplished by: > > > >

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 9 Sep 2014 03:25, "Jim J. Jewett" wrote: > Examples of good enough: > "Add this file to site-packages" > "Add this environment variable with this setting" > "Add this command line switch to your launch script" The monkeypatching hack I proposed would work correctly in sitecustomize

Re: [Python-Dev] Proposed schedule for 3.4.2

On 9 Sep 2014 08:30, "Donald Stufft" wrote: > > If someone wants to do this, can’t they write their own 6 line function? Unfortunately not, as the domain knowledge required to know what those six lines should look like is significant. Keeping the old unsafe behaviour around with a more obviously

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 9 Sep 2014 10:48, "Jim J. Jewett" wrote: > I assume that adding _unverified_urlopen or urlopen(context=...) do > provide incremental improvements compatible with the eventual full > opt-in. If so, adding them is probably reasonable, but I think the > PEP should explicitly list all such approve

[Python-Dev] Suggested changes to verify HTTPS by default (was Re: Proposed schedule for 3.4.2)

would then be a matter of bringing urllib, urllib2, httplib and ssl into line with their 3.4.2 counterparts. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.py

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 10 Sep 2014 02:11, "Christian Heimes" wrote: > > On 09.09.2014 05:03, Nick Coghlan wrote: > > > > On 9 Sep 2014 10:48, "Jim J. Jewett" > <mailto:jimjjew...@gmail.com>> wrote: > >> I assume that adding _unverified_urlopen or ur

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 10 September 2014 07:13, Jim J. Jewett wrote: > On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes > wrote: >> On 09.09.2014 05:03, Nick Coghlan wrote: >>> >>> On 9 Sep 2014 10:48, "Jim J. Jewett" >> <mailto:jimjjew...@gmail.com>> wrote:

[Python-Dev] Multilingual programming article on the Red Hat Developer blog

ost of our redistributors and many of our key users are helping to push the migration forward, while we also continue to support existing Python 2 users :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python

Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog

On 13 Sep 2014 10:18, "Jeff Allen" wrote: > 4. I think (with Antoine) if Jython supported PEP-383 byte smuggling, it would have to do it the same way as CPython, as it is visible. It's not impossible (I think), but is messy. Some are strongly against. It may be worth trying *without* it (i.e. tre

Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog

On 14 Sep 2014 01:33, "R. David Murray" wrote: > > On Sat, 13 Sep 2014 21:06:21 +1200, Nick Coghlan wrote: > > On 13 Sep 2014 10:18, "Jeff Allen" wrote: > > > 4. I think (with Antoine) if Jython supported PEP-383 byte smuggling, it > > would

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

On 19 Sep 2014 17:38, "Bohuslav Kabrda" wrote: > - "Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3." > > The important word in the second point is, I think, *whenev

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

ike, so far down I can't even see it any more). I'd be willing to review proposals, though :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.

Re: [Python-Dev] PEP476: Enabling certificate validation by default

sing, but as a matter of practical reality, corporate IT departments are chronically understaffed, and often fully committed to fighting the crisis du jour, without sufficient time being available for regular infrastructure maintenance tasks. Regards, Nick. -- Nick Coghlan | ncogh...@

Re: [Python-Dev] PEP476: Enabling certificate validation by default

ntenance branches. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PEP476: Enabling certificate validation by default

so need some clarification from Ned regarding the status of OpenSSL and the potential impact switching from dynamic linking to static linking of OpenSSL may have in terms of the "OPENSSL_X509_TEA_DISABLE" setting. Regards, Nick. -- Nick Coghlan |

Re: [Python-Dev] 3.5 release schedule PEP

isting stream (http://bugs.python.org/issue15216) (432 was previously listed as deferred, but it went back on my todo list once 3.4 was out the door) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mai

Re: [Python-Dev] 3.5 release schedule PEP

On 23 September 2014 19:46, Nick Coghlan wrote: > Under consideration (in addition to the items already listed in the PEP): > > PEP 432 (simplifying the startup sequence) > PEP 475 (retry system calls failing with EINTR) > Improved Windows console Unicode suppo

Re: [Python-Dev] 3.5 release schedule PEP

;s tighter than I thought... > > Thoughts, anyone? It's ultimately up to Larry as RM, but I'd personally favour targeting the newer compiler and runtime, even with the slight risk of potentially needing to slip our schedule. There's also a fair amount of wiggle room between the f

Re: [Python-Dev] 3.5 release schedule PEP

On 24 Sep 2014 15:15, "Tim Golden" wrote: > > On 23/09/2014 18:05, Steve Dower wrote: >> >> I'm also considering/experimenting with installing into "Program >> Files" by default, but I suspect that isn't going to work out yet. > > > I'd like to see that go forward: I think it's increasingly diffic

Re: [Python-Dev] 3.5 release schedule PEP

y a transient one during the 3.4 pre-release cycle (the ensurepip integration initially didn't work properly when installing into Program Files). So consider that a switch to +1 from me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-Dev] 3.5 release schedule PEP

On 26 Sep 2014 01:56, "Paul Moore" wrote: > > Basically, I'd like to hold off moving to "Program Files" as a default > until *after* we have enough confidence in user installs that we are > willing to switch pip to --user as the default behaviour everywhere. > And yes, I'm aware that the first "we

Re: [Python-Dev] 3.5 release schedule PEP

On 27 Sep 2014 14:19, "Chris Barker" wrote: > > All this is also making me think that virtualenv and friends is the real solution to user installed packages anyway. The main use case that doesn't cover is system scripting on Linux, where you may want access to all the platform specific libraries.

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

(the thread was before Steve's announcement of the more readily available VC9 compiler download). Cheers, Nick. P.S. Note that pip always runs setup.py via setuptools, so updating setuptools also deals with the general "pip install" case of building fr

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

w). I also pushed a few tweaks to account for the extension of Python 2.7 maintenance, and to change the verb tense to reflect the fact this was implemented ages ago [3]. Cheers, Nick. [1] https://hg.python.org/peps/rev/3d16b0cd10bc [2] https://hg.python.org/peps/rev/32b6619e9259 [3] https://hg.p

Re: [Python-Dev] Sysadmin tasks

On 2 Oct 2014 06:26, "Daniel Holth" wrote: > > On Wed, Oct 1, 2014 at 1:59 PM, Mark Shannon wrote: > > Hi, > > > > http://speed.python.org/ > > could do with some love. > > +1 Indeed :) More generally, see the list Benjamin Peterson put together at https://wiki.python.org/moin/PSFInfrastructure

Re: [Python-Dev] Backporting ensurepip to 2.7, Which commands to install?

PEP 394, which specifies the following behaviour when installing Python itself: Python 2.7: python, python2, python2.7 Python 3.4: python3, python3.4 That maps to ensurepip as: Python 2.7: pip, pip2, pip2.7 Python 3.4: pip3, pip3.4 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.

Re: [Python-Dev] bytes-like objects

r or not "memoryview(obj)" works. An object can be bytes like without supporting the full bytes/bytearray API. Some APIs that theoretically *could* accept arbitrary bytes like objects are currently more limited - expanding those cases to accept arbitrary bytes-like objects is generall

Re: [Python-Dev] bytes-like objects

ne a bytes-like type?" is: 1. Use the appropriate implementation specific buffer protocols; or 2. Inherit from an existing bytes-like type Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing

Re: [Python-Dev] bytes-like objects

()) and exclusions (like strings and bytes objects). Navigating the grey area can then be postponed until later (and for many users, it will never be necessary to navigate it at all). If anything, bytes-like object is *better* defined than file-like object, since the one thing that is expected to

Re: [Python-Dev] bytes-like objects

On 7 Oct 2014 00:31, "Christian Tismer" wrote: > > 2) > And about this glossary entry: > > "An object that supports the Buffer Protocol" > - can I take that for granted, as a real definition, meaning > > """an object is bytes-like iff it supports the buffer protocol"""? Yes, although we should l

Re: [Python-Dev] Status of C compilers for Python on Windows

On 12 Oct 2014 04:20, "Steve Dower" wrote: > > DLLs linked by import library at compile time (ie. not using LoadLibrary calls) and placed in the same directory as the .pyd should be exempt from DLL hell - Python already creates an activation context when importing pyds to let them load their own d

Re: [Python-Dev] PEP476: Enabling certificate validation by default

On 13 Oct 2014 08:58, "Guido van Rossum" wrote: > > I see no reason to hold up this PEP's approval any longer, so I hereby approve PEP 476. It looks like a fair amount of work is still needed to backport this to Python 2.7 (and a smaller amount for 3.4) but I trust that this will all happen before

Re: [Python-Dev] Backporting ensurepip to 2.7, Which commands to install?

indows is a little different, as the Python 3 executable has always remained "python.exe" there. Originally we followed PEP 394 style naming on Windows as well, but then realised during the 3.4 beta cycle that doing so didn't actually make sense (see http://bugs.python.org/issue20568 an

Re: [Python-Dev] Status of C compilers for Python on Windows

umption will allow MinGW-w64 to link with the appropriate MSVCRT versions for extention building without anything breaking. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] Status of C compilers for Python on Windows

sing MinGW-w64 for cross-compilation of Windows binaries, it may make sense to incorporate the patches that allow building with MinGW-w64 into mainline CPython (if I recall correctly, we supported building with Intel's C compiler for a long time, even though we never shipped anything built

Re: [Python-Dev] Status of C compilers for Python on Windows

/www.microsoft.com/en-us/download/details.aspx?id=44266), it's more about: * wanting to build for Windows within the scope of an existing POSIX based build automation system * folks that prefer to use only open source software themselves wanting to make their projects available to Window

Re: [Python-Dev] Status of C compilers for Python on Windows

developers. Those differing assumptions then meant that the two groups end up frequently talk past each other because the worldviews are too different. While that's starting to improve of late (as the above distinction becomes better recognised), there's still a long way to go. Re

Re: [Python-Dev] 2.7.9 schedule redux

with ensurepip, and the mock-based tests for ensurepip cover the 2.7 backport itself, I think we still have an acceptable level of regression testing coverage, even without being able to backport the venv based functional tests. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Bri

Re: [Python-Dev] The role of NotImplemented: What is it for and when should it be used?

It's worth noting that as far as I am aware, all the cases where CPython currently raises TypeError directly rather than returning NotImplemented are due to a longstanding bug in the handling concatenation and repetition of sequences implemented entirely in C (which includes the builtins): http://b

Re: [Python-Dev] Real-world use of Counter

On 6 Nov 2014 06:53, "Alexander Belopolsky" wrote: > > > On Wed, Nov 5, 2014 at 2:47 PM, R. David Murray wrote: >> >> As I said on the issue, there is no reason I can see to add extra code >> just to turn an AttributeError into a TypeError. The AttributeError >> works just fine in letting you kn

Re: [Python-Dev] [Python-checkins] cpython (2.7): #22650: test suite: load Unicode test data files from www.pythontest.net

On 7 Nov 2014 02:44, "Georg Brandl" wrote: > > On 11/06/2014 03:39 PM, Brett Cannon wrote: > > What is pythontest.net ? Is it something we control, and > > if so how do we add things to it for tests? Did I miss an email on python-dev or > > python-committers about this? > >

Re: [Python-Dev] Who's using VS/Windows to work on Python?

#x27;re going to need to be able to explain that to new Windows based contributors. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/li

Re: [Python-Dev] OneGet provider for Python

haps in https://packaging.python.org/en/latest/deployment.html#os-packaging-installers although that section is currently still just a stub) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailin

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

r be allowed, which means no more "or stop()" tricks to get generator expressions to terminate early. (If folks wanted to restore that capability, they'd instead need to propose new syntax that works the same way in both comprehensions and generator expressions, rat

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

m __future__ import generator_return". I saw that style as somewhat similar to "from __future__ import division" - it just tells you what the change affects (in this case, returning from generators), while requiring folks to look up the documentation to find out t

[Python-Dev] Move selected documentation repos to PSF BitBucket account?

break automated regeneration of associated site elements, but that's still a lot simpler than adding an entirely new piece of infrastructure. If folks are amenable to that variant of the idea, I'll undefer PEP 474 and revise it accordingly, with the developer guide and the PEP&#

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 21 November 2014 23:29, Brett Cannon wrote: > On Fri Nov 21 2014 at 7:37:13 AM Nick Coghlan wrote: >> If that "must be self-hosted" constraint is removed, then the obvious >> candidate for Mercurial hosting that supports online editing + pull >> requests

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

esting that and actually getting it are two different things, > especially when I don't know of any way to rewrite a commit message after > the fact if we go back to someone and say "your commit message is bad, > please fix it". Worst case? Ask them to submit a new pull reque

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 22 November 2014 00:03, Nick Coghlan wrote: > On 22 November 2014 00:00, Brett Cannon wrote: >>> As far as ignoring PR noise goes, we can still request that folks >>> squash any commits (keep in mind that the proposal is only to move >>> pure documentation re

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On 22 Nov 2014 02:51, "Antoine Pitrou" wrote: > > On Fri, 21 Nov 2014 05:47:58 -0800 > Raymond Hettinger wrote: > > > > Another issue is that it breaks the way I and others have taught for years that generators are a kind of iterator (an object implementing the iterator protocol) and that a prima

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 22 Nov 2014 07:37, "Donald Stufft" wrote: > > On Nov 21, 2014, at 3:59 PM, Ned Deily wrote: > > Sure, I get that. But we're not even talking here about the main Python > > docs since they are part of the CPython repos, only ancillary repos like > > PEPs and the developer's guide. The level o

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

ain. Note that if folks prefer Git, BitBucket supports both. I would object strongly to unilaterally forcing existing contributors to switch from Mercurial to git. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 23 November 2014 at 16:03, Donald Stufft wrote: >> On Nov 23, 2014, at 12:59 AM, Nick Coghlan wrote: >> >> Note that if folks prefer Git, BitBucket supports both. I would object >> strongly to unilaterally forcing existing contributors to switch from >> Mercuria

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 23 November 2014 at 16:10, Guido van Rossum wrote: > On Saturday, November 22, 2014, Nick Coghlan wrote: >> The learning curve on git is still awful - it offers no compelling >> advantages over hg, and GitHub doesn't offer any huge benefits over >> BitBucket for

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 23 November 2014 at 16:27, Donald Stufft wrote: >> On Nov 23, 2014, at 1:25 AM, Nick Coghlan wrote: >> By contrast, proposals to switch from Mercurial to Git impose a >> *massive* burden on contributors that don't already know git. That >> significant increase in

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 23 November 2014 at 17:14, Donald Stufft wrote: >> On Nov 23, 2014, at 2:01 AM, Nick Coghlan wrote: >> Travis isn't the only CI system on the internet, and for pure Sphinx >> documentation cases, ReadTheDocs runs just as well off BitBucket as it >> does off GitHu

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 23 Nov 2014 18:11, "Donald Stufft" wrote: > > On Nov 23, 2014, at 2:35 AM, Nick Coghlan wrote: > > > > In the absence of a proposal to change version control systems > > (again), the lack of Mercurial hosting on GitHub makes it rather a > > moot point

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 24 November 2014 at 02:55, Brett Cannon wrote: > On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan wrote: >> Those features are readily accessible without changing the underlying >> version control system (whether self-hosted through Kallithea or externally >> hosted

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

typo or other small, easy to fix error in docs, going to the source page, hitting Edit, and submitting the PR that I like with the online editing support. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 24 Nov 2014 10:41, "Donald Stufft" wrote: > > > > On Nov 23, 2014, at 6:57 PM, Steven D'Aprano wrote: > > > > On Sun, Nov 23, 2014 at 08:55:50AM -0800, Guido van Rossum wrote: > > > >> But I strongly believe that if we want to do the right thing for the > >> long term, we should switch to GitH

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

> On Nov 23, 2014, at 1:49 AM, Nick Coghlan wrote: >>> >>> I took the git knowledge I acquired by necessity at Red Hat and >>> figured out how to apply it to hg. All the same features are there in >>> hg, they're just switched off by default (mainly bec

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

r BitBucket, or GitLab, etc. So you may as well go with one of the open source ones, and be *completely* free from vendor lockin. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 25 Nov 2014 02:28, "Brett Cannon" wrote: > > > > On Mon Nov 24 2014 at 2:25:30 AM Nick Coghlan wrote: >> >> On 24 November 2014 at 02:55, Brett Cannon wrote: >> > On Sun Nov 23 2014 at 6:18:46 AM Nick Coghlan wrote: >> >> Those features

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

On 25 Nov 2014 06:25, "Donald Stufft" wrote: > > >> On Nov 24, 2014, at 2:55 PM, Nick Coghlan wrote: >> >> It may not have been Guido's intention, but his proposal to undercut the entire Python based version control tooling ecosystem by deeming it entirely

Re: [Python-Dev] Please reconsider PEP 479.

t with the fact that logging.warn() is for cases that are dubious and should potentially be investigated by the application developer, but there's no specific code change to be made to avoid the warning. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

keeping that in mind as I work to get the proof-of-concept forge instance online. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/l

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

e if it's the StopIteration instance that was thrown in, but an alternative option would be to just call gen.close() in that case, rather than gen.throw(exc). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-Dev] Please reconsider PEP 479.

s convinced this part is a good idea, if "allow_implicit_stop" accepted both generator functions *and* generator objects, then folks could even still explicitly opt in to the "or stop()" trick - and anyone reading the code would have a name to look up to see what was going on.

Re: [Python-Dev] Please reconsider PEP 479.

On 26 November 2014 at 21:44, Petr Viktorin wrote: > On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan wrote: >> Now needs to be written out explicitly as: >> >> def my_generator(): >> ... >>try: >> yield next(it) >>

Re: [Python-Dev] Please reconsider PEP 479.

On 27 Nov 2014 06:35, "Guido van Rossum" wrote: > > On Wed, Nov 26, 2014 at 3:24 AM, Nick Coghlan wrote: >> After thinking about that concern for a while, I'd like to suggest the >> idea of having a new builtin "allow_implicit_stop" decorator that &g

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On 27 Nov 2014 03:58, "Paul Moore" wrote: > > On 26 November 2014 at 17:19, Guido van Rossum wrote: > > It's hard to use as an example because the behavior of contextlib is an > > integral part of it -- currently for me the example boils down to "there is > > a bug in contextlib" > > Hmm, fair po

Re: [Python-Dev] Please reconsider PEP 479.

On 27 November 2014 at 11:15, Guido van Rossum wrote: > On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan wrote: >> >> On 27 Nov 2014 06:35, "Guido van Rossum" wrote: >> >> [...] >> >> > I think we can put a number to "much faster"

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On 27 November 2014 at 09:50, Guido van Rossum wrote: > On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan wrote: >> This is actually the second iteration of this bug: the original >> implementation *always* suppressed StopIteration. PJE caught that one before >> Python 2.5

Re: [Python-Dev] Strange "help(int.__lt__)". Probably documentation bug

ection APIs) to inspect.signature in Python 3.4 entailed having an unambiguous string representation of positional only parameters - that's the trailing '/' (which mirrors the corresponding syntax in the Argument Clinic DSL). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisb

Re: [Python-Dev] Please reconsider PEP 479.

On 28 November 2014 at 02:52, Guido van Rossum wrote: > On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan wrote: >> If compatibility with older Python versions is needed, then you could >> put something like the following in a compatibility module: >> >> try: >&

Re: [Python-Dev] PEP 479 and asyncio

want to understand the code, they have to know how Python X.Y worked, rather than being able to assume modern Python. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

ork workflow while working on multiple patches > concurrently and keeping master in sync with hg default (or perhaps > even both). As far as I'm aware, the easiest way to do that by using git-remote-hg to treat the CPython Mercurial repository as a git remote (although I've never tr

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

matter, not just >> __dict__. Usage: > > How do these two options interact with the fact that module functions > store their globals dict, not the module itself? Right, that's the part I consider the most challenging with metamodules - the fact that there's a longstanding

Re: [Python-Dev] PEP 479 and asyncio

is particular system, the overhead was around 150 ns per link in the chain at the point the data processing pipeline was shut down. In most scenarios where a data processing pipeline is worth setting up in the first place, the per-item handling costs (which won't change) are likely to overwhel

<    1   2   3   4   5   6   7   8   9   10   >