On Fri, Nov 21, 2014 at 9:26 PM, Tshepang Lekhonkhobe
wrote:
> On Fri, Nov 21, 2014 at 8:46 PM, Guido van Rossum
> wrote:
> > Like it or not, github is easily winning this race.
>
> Are you considering moving CPython development to Github?
>
No, but I prefer it for new projects.
--
--Guido v
On Fri, Nov 21, 2014 at 8:46 PM, Guido van Rossum wrote:
> Like it or not, github is easily winning this race.
Are you considering moving CPython development to Github?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
Hi,
Anyway, I think we must change CPython to support tools such as perf. Any
> thoughts?
>
Not many thoughts, other than that it would be nice to be able to use a
sampling profiler on Python code. I think this would especially benefit
applications that use libraries written in C, or applications
> On Nov 21, 2014, at 3:59 PM, Ned Deily wrote:
>
> In article <19336614-0e4f-42bf-a918-1807bb7f3...@stufft.io>,
> Donald Stufft wrote:
> [...]
>> Well you can’t document your way out of a bad UX. The thing you’re
>> competing with (on Github at least) is:
>>
>> 1. I notice a docs change I can
In article <19336614-0e4f-42bf-a918-1807bb7f3...@stufft.io>,
Donald Stufft wrote:
[...]
> Well you can’t document your way out of a bad UX. The thing you’re
> competing with (on Github at least) is:
>
> 1. I notice a docs change I can make
> 2. I click the “Edit” button and it automatically crea
> On Nov 21, 2014, at 3:04 PM, Ned Deily wrote:
>
> In article <20141121102647.46e97...@limelight.wooz.org>,
> Barry Warsaw wrote:
>
>> On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:
>>
>>> I'd been taking "must be hosted in PSF infrastructure" as a hard
>>> requirement, but MAL pointed ou
In article <20141121102647.46e97...@limelight.wooz.org>,
Barry Warsaw wrote:
> On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:
>
> >I'd been taking "must be hosted in PSF infrastructure" as a hard
> >requirement, but MAL pointed out earlier this evening that in the age
> >of DVCS's, that requ
Like it or not, github is easily winning this race.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
On Fri, Nov 21, 2014 at 9:18 AM, Steven D'Aprano
wrote:
> I fear that there is one specific corner case that will be impossible to
> deal with in a backwards-compatible way supporting both Python 2 and 3
> in one code base: the use of `return value` in a generator.
>
> In Python 2.x through 3.1,
On Fri, Nov 21, 2014 at 8:47 AM, 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
On Thu, Nov 20, 2014 at 11:36:54AM -0800, Guido van Rossum wrote:
[...]
> That said, I think for most people the change won't matter, some people
> will have to apply one of a few simple fixes, and a rare few will have to
> rewrite their code in a non-trivial way (sometimes this will affect
> "cle
ACTIVITY SUMMARY (2014-11-14 - 2014-11-21)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4658 (+11)
closed 30014 (+28)
total 34672 (+39)
Open issues wit
> Antoine Pitrou wrote:
> On Fri, 21 Nov 2014 13:29:11 +
> Brett Cannon wrote:
>>> If that "must be self-hosted" constraint is removed, then the
>>> obvious candidate for Mercurial hosting that supports online editing
>>> + pull requests is the PSF's BitBucket account.
>>>
>>
>> There's also C
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 primary motivation for generators is to provide a
> si
On Sat, Nov 22, 2014 at 3:37 AM, Donald Stufft wrote:
> I don’t have an opinion on whether it’s enough of a big deal to actually
> change
> it, but I do find wrapping it with a try: except block and returning easier
> to understand. If you showed me the current code unless I really thought about
On Fri, 21 Nov 2014 11:03:35 -0500
Benjamin Peterson wrote:
>
> I hate to say this, but if we're going to have "doc" repos hosted in a
> different place than code, we might as bite the bullet and move them to
> Git + GitHub. That would surely maximize the community size + ease of
> use objective
On Fri, 21 Nov 2014 13:29:11 +
Brett Cannon wrote:
> > If that "must be self-hosted" constraint is removed, then the obvious
> > candidate for Mercurial hosting that supports online editing + pull
> > requests is the PSF's BitBucket account.
> >
>
> There's also CodePlex and (ironically) Sour
> On Nov 21, 2014, at 11:31 AM, Ethan Furman wrote:
>
> On 11/21/2014 05:47 AM, Raymond Hettinger wrote:
>>
>> Also, the proposal breaks a reasonably useful pattern of calling
>> next(subiterator)
>> inside a generator and letting the generator terminate when the data stream
>> ends.
>>
>>
On 11/21/2014 05:47 AM, Raymond Hettinger wrote:
>
> Also, the proposal breaks a reasonably useful pattern of calling
> next(subiterator)
> inside a generator and letting the generator terminate when the data stream
> ends.
>
> Here is an example that I have taught for years:
>
> def [...]
On 21 November 2014 15:58, Steven D'Aprano wrote:
>> > def izip(iterable1, iterable2):
>> > it1 = iter(iterable1)
>> > it2 = iter(iterable2)
>> > while True:
>> > v1 = next(it1)
>> > v2 = next(it2)
>> > yield v1, v2
>>
>> Is it obviou
On Sat, Nov 22, 2014 at 2:58 AM, Steven D'Aprano wrote:
> Since zip() is documented as
> halting on the shorter argument, it can't raise an exception. So what
> other options are there apart from silently consuming the value?
Sure, it's documented as doing that. But imagine something that isn't
a
On Fri, Nov 21, 2014, at 11:00, Donald Stufft wrote:
>
> > On Nov 21, 2014, at 10:26 AM, Barry Warsaw wrote:
> >
> > On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:
> >
> >> I'd been taking "must be hosted in PSF infrastructure" as a hard
> >> requirement, but MAL pointed out earlier this e
On Fri, Nov 21, 2014, at 07:36, Nick Coghlan wrote:
> For those that aren't aware, PEP 474 is a PEP I wrote a while back
> suggesting we set up a "forge.python.org" service that provides easier
> management of Mercurial repos that don't have the complex branching
> requirements of the main CPytho
> On Nov 21, 2014, at 10:26 AM, Barry Warsaw wrote:
>
> On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:
>
>> I'd been taking "must be hosted in PSF infrastructure" as a hard
>> requirement, but MAL pointed out earlier this evening that in the age
>> of DVCS's, that requirement may not make se
On Sat, Nov 22, 2014 at 12:53:41AM +1100, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> wrote:
> > Also, the proposal breaks a reasonably useful pattern of calling
> > next(subiterator) inside a generator and letting the generator terminate
> > when the data stream
On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:
>I'd been taking "must be hosted in PSF infrastructure" as a hard
>requirement, but MAL pointed out earlier this evening that in the age
>of DVCS's, that requirement may not make sense: if you avoid tightly
>coupling your automation to a particular
On 21 November 2014 13:53, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> wrote:
>> Also, the proposal breaks a reasonably useful pattern of calling
>> next(subiterator) inside a generator and letting the generator terminate
>> when the data stream ends. Here is a
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 repos, so long complex PR chains seem
On Fri Nov 21 2014 at 8:57:15 AM Nick Coghlan wrote:
> 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 e
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 repos, so long complex PR chains seem unlikely).
>
> Well, requesting that and actually ge
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 is the PSF's BitBucket account.
>
> The
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
wrote:
> Also, the proposal breaks a reasonably useful pattern of calling
> next(subiterator) inside a generator and letting the generator terminate
> when the data stream ends. Here is an example that I have taught for
> years:
>
> def izi
> On Nov 19, 2014, at 12:10 PM, Guido van Rossum wrote:
>
> There's a new PEP proposing to change how to treat StopIteration bubbling up
> out of a generator frame (not caused by a return from the frame). The
> proposal is to replace such a StopIteration with a RuntimeError (chained to
> the
On Fri Nov 21 2014 at 7:37:13 AM Nick Coghlan wrote:
> For those that aren't aware, PEP 474 is a PEP I wrote a while back
> suggesting we set up a "forge.python.org" service that provides easier
> management of Mercurial repos that don't have the complex branching
> requirements of the main CPyth
For those that aren't aware, PEP 474 is a PEP I wrote a while back
suggesting we set up a "forge.python.org" service that provides easier
management of Mercurial repos that don't have the complex branching
requirements of the main CPython repo. Think repos like the PEPs repo,
or the developer guide
35 matches
Mail list logo
