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

2014-11-21 Thread Nick Coghlan 
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 repo.

The primary objective of the PEP is to enable an online editing + pull
request style workflow for these pure documentation projects that only
have a single active branch.

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 DVCS host's infrastructure,
then reverting back to self-hosting (if that becomes necessary for
some reason) is mostly just a matter of "hg push".

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'd still be some work in such a change to make sure we didn't
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's
repo as the initially proposed candidates for transfer.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Brett Cannon 
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 CPython repo. Think repos like the PEPs repo,
> or the developer guide repo.
>
> The primary objective of the PEP is to enable an online editing + pull
> request style workflow for these pure documentation projects that only
> have a single active branch.
>
> 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 DVCS host's infrastructure,
> then reverting back to self-hosting (if that becomes necessary for
> some reason) is mostly just a matter of "hg push".
>

I don't view self-hosting as ever being a requirement. We hosted ourselves
mainly to fully control commit messages (we do like to be very explicit
after all =). Because we didn't want to pollute our message log with
people's own messages which didn't follow our commit log guidelines or were
of high enough caliber, we chose to fully control the hosting so as to not
give people a false hope that we would accept a pull request.


>
> 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) SourceForge for open-source hg
hosting.


>
> There'd still be some work in such a change to make sure we didn't
> 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's
> repo as the initially proposed candidates for transfer.
>

I think showing us how to ignore PR comments and only show those from
merges and direct commits on a branch (e.g. blame, reading log output,
etc.) would help, i.e. how to work with Mercurial so I only see commit
messages from core developers or ones they directly could edit?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Raymond Hettinger 

> 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 original StopIteration), so that only *returning* from a generator (or 
> falling off the end) causes the iteration to terminate.
> 
> The proposal unifies the behavior of list comprehensions and generator 
> expressions along the lines I had originally in mind when they were 
> introduced. It renders useless/illegal certain hacks that have crept into 
> some folks' arsenal of obfuscated Python tools.

I strongly recommend against accepting this PEP.

The PEP itself eloquently articulates an important criticism, "Unofficial and 
apocryphal statistics suggest that this is seldom, if ever, a problem. [4]  
Code does exist which relies on 
the current behaviour (e.g. [2]  
, [5]  
, [6]  
), and there is the concern 
that this would be unnecessary code churn to achieve little or no gain.".

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 simpler 
and more direct way of creating iterators.  However, Chris explained that, 
"This proposal causes a separation of generators and iterators, so it's no 
longer possible to pretend that they're the same thing."  That is a major and 
worrisome conceptual shift.

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 izip(iterable1, iterable2):
it1 = iter(iterable1)
it2 = iter(iterable2)
while True:
v1 = next(it1)
v2 = next(it2)
yield v1, v2

The above code is not atypical.  Several of the pure python equivalents in the 
itertools docs have documented this pattern to the world for over a decade.  I 
have seen it other people's code bases as well (in several contexts including 
producer/consumer chains, generators that use next() to fetch initial values 
from a stream, and generators that have multiple subiterators).  This behavior 
was guaranteed from day one in PEP 255, so we would be breaking a 
long-standing, published rule.

Adding a try/except to catch the StopIteration make the above code compliant 
with the new PEP, but it wouldn't make the code better in any way.  And after 
that fix, the code would be less beautiful that it is now, and I think that 
matters.

Lastly, as I mentioned on python-ideas, if we really want people to migrate to 
Python 3, there should be a strong aversion to further increasing the semantic 
difference between Python 2 and Python 3 without a really good reason.


Raymond


P.S.  The PEP 255 promise was also announced as a practice in the WhatsNew 2.2 
document (where most people first learned what generators are and how to use 
them), "The end of the generator’s results can also be indicated by raising 
StopIteration  
manually, or by just letting the flow of execution fall off the bottom of the 
function."   The technique was also used in the generator tutorial (which was 
tested Lib/test/test_generators.py).

One other thought:  A number of other languages have added generators modeled 
on the Python implementation.   It would be worthwhile to check to see what the 
prevailing wisdom is regarding whether it should be illegal to raise 
StopIteration inside a generator.
 ___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Chris Angelico 
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 izip(iterable1, iterable2):
> it1 = iter(iterable1)
> it2 = iter(iterable2)
> while True:
> v1 = next(it1)
> v2 = next(it2)
> yield v1, v2

Is it obvious to every user that this will consume an element from
it1, then silently terminate if it2 no longer has any content?

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Nick Coghlan 
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.
>
> There's also CodePlex and (ironically) SourceForge for open-source hg
> hosting.

Did SF end up actually integrating Hg hosting properly? They hadn't
the last time I looked - it was still a third party addon to Allura.

I'll spell this out in the PEP, but the reason I suggest BitBucket in
particular is:

- it's written in Python
- the PSF already has an organisational account set up there
- I have admin access, so I can bootstrap other folks as
administrators (Christian Heimes & Brian Curtin are also admins)
- I know the online editing works reliably, since I maintain the PyPI
metadata PEP drafts there
- having used both it and GitHub extensively, I'm confident the
workflows are similar enough that anyone familiar with GitHub will be
able to easily pick up the BitBucket UI

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

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Nick Coghlan 
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 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 request.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Brett Cannon 
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 editing + pull
> >> requests is the PSF's BitBucket account.
> >
> > There's also CodePlex and (ironically) SourceForge for open-source hg
> > hosting.
>
> Did SF end up actually integrating Hg hosting properly? They hadn't
> the last time I looked - it was still a third party addon to Allura.
>
> I'll spell this out in the PEP, but the reason I suggest BitBucket in
> particular is:
>
> - it's written in Python
> - the PSF already has an organisational account set up there
> - I have admin access, so I can bootstrap other folks as
> administrators (Christian Heimes & Brian Curtin are also admins)
> - I know the online editing works reliably, since I maintain the PyPI
> metadata PEP drafts there
> - having used both it and GitHub extensively, I'm confident the
> workflows are similar enough that anyone familiar with GitHub will be
> able to easily pick up the BitBucket UI
>

You're putting more thought into the response than I did in the suggestion.
=) I just know they claim to host hg repos.


>
> 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 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".
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Nick Coghlan 
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 unlikely).
>>
>> Well, requesting 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 request.

Oh, the other option is to pull the patch from the PR, apply it
locally, and then use "hg commit --amend". It's still Mercurial under
the hood, it's just got a streamlined single-click workflow for the
cases where the patch doesn't need amending.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Paul Moore 
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 an example that I have taught for
>> years:
>>
>> def izip(iterable1, iterable2):
>> it1 = iter(iterable1)
>> it2 = iter(iterable2)
>> while True:
>> v1 = next(it1)
>> v2 = next(it2)
>> yield v1, v2
>
> Is it obvious to every user that this will consume an element from
> it1, then silently terminate if it2 no longer has any content?

It is to me, certainly.

I'm mostly with Raymond on this. The main exception is that there does
seem to be a trend towards more "tricky" uses of this feature,
typically around ideas such as a stop() function to break out of
generator expressions. I do think this is bad practice and shouldn't
be allowed.

But given that it's possible to write bad code in plenty of ways, and
changing the language "to protect people from themselves" is not a
good idea, I don't think the benefits justify the change [1].

Paul

[1] Probably simply telling people not to try to cram over-complex
code into a genexp would address the worst aspects of the problem...
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Barry Warsaw 
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 DVCS host's infrastructure,
>then reverting back to self-hosting (if that becomes necessary for
>some reason) is mostly just a matter of "hg push".
>
>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.

For the record, I object to moving *official* PSF resources to proprietary,
closed-source infrastructure that we do not control or have access to[*].

As nice and friendly as BitBucket or any other code hosting source is today,
there are many reasons why I think this is a bad idea for *official*
branches.  We are beholden to their policies and operations, which may not
align with PSF policies or principles today or in the future.  We will not be
able to customize the experience for our own needs.  We will not have access
to the underlying resources should we need them for any purpose.  We cannot
take action ourselves if some problem occurs, e.g. banning an offensive user.

You're right that in a world of dvcs, branches can be mirrored anywhere.  For
that reason, I have no problem allowing developers to use non-PSF controlled
resources *unofficially* if it makes their work easier and doesn't conflict
with their own principles.  However, in such cases, I still believe that the
official, master, blessed repositories remain on PSF controlled
infrastructure.  Surely that too is possible in the world of dvcs, right?

Cheers,
-Barry

[*] Please note that I am not objecting to our use of lower-level resources
donated by our generous sponsors.  It's a fine line perhaps, but I have no
problem with a wiki running on a VM hosted on some donated hardware, since we
still have full access to the machine, the OS, and the application software.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Steven D'Aprano 
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  ends.  Here is an example that I have taught for
> > years:
> >
> > def izip(iterable1, iterable2):
> > it1 = iter(iterable1)
> > it2 = iter(iterable2)
> > while True:
> > v1 = next(it1)
> > v2 = next(it2)
> > yield v1, v2
> 
> Is it obvious to every user that this will consume an element from
> it1, then silently terminate if it2 no longer has any content?

"Every user"? Of course not. But it should be obvious to those who think 
carefully about the specification of zip() and what is available to 
implement it.

zip() can't detect that the second argument is empty except by calling 
next(), which it doesn't do until after it has retrieved a value from 
the first argument. If it turns out the second argument is empty, what 
can it do with that first value? It can't shove it back into the 
iterator. It can't return a single value, or pad it with some sentinel 
value (that's what izip_longest does). 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?

Indeed that is exactly what the built-in zip does:

py> a = iter("abcdef")
py> b = iter("abc")
py> list(zip(a, b))
[('a', 'a'), ('b', 'b'), ('c', 'c')]
py> next(a)
'e'


-- 
Steven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Donald Stufft 

> 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 sense: if you avoid tightly
>> coupling your automation to a particular DVCS host's infrastructure,
>> then reverting back to self-hosting (if that becomes necessary for
>> some reason) is mostly just a matter of "hg push".
>> 
>> 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.
> 
> For the record, I object to moving *official* PSF resources to proprietary,
> closed-source infrastructure that we do not control or have access to[*].
> 
> As nice and friendly as BitBucket or any other code hosting source is today,
> there are many reasons why I think this is a bad idea for *official*
> branches.  We are beholden to their policies and operations, which may not
> align with PSF policies or principles today or in the future.  We will not be
> able to customize the experience for our own needs.  We will not have access
> to the underlying resources should we need them for any purpose.  We cannot
> take action ourselves if some problem occurs, e.g. banning an offensive user.
> 
> You're right that in a world of dvcs, branches can be mirrored anywhere.  For
> that reason, I have no problem allowing developers to use non-PSF controlled
> resources *unofficially* if it makes their work easier and doesn't conflict
> with their own principles.  However, in such cases, I still believe that the
> official, master, blessed repositories remain on PSF controlled
> infrastructure.  Surely that too is possible in the world of dvcs, right?
> 
> Cheers,
> -Barry
> 
> [*] Please note that I am not objecting to our use of lower-level resources
> donated by our generous sponsors.  It's a fine line perhaps, but I have no
> problem with a wiki running on a VM hosted on some donated hardware, since we
> still have full access to the machine, the OS, and the application software.

Personally I care less about proprietary and closed-source and care a lot more
about lock-in. Thus my big problem using Bitbucket for these things is that if
we ever want to *leave* bitbucket it becomes a lot harder because you have a
bunch of links and such pointing at bitbucket instead of a python.org domain.
They do offer a redirect feature but that is dependent on them not taking that
away in the future. (They also offer a CNAME feature but if you use it you lose
the ability to use TLS, which is also a non starter for me). Sadly this also
leaves out my favorite host site of Github :/. Something like Github Enterprise
or Atlassian stash which are able to be migrated away from are better in this
regards.

Ironically we do use a propetiary/closed-source/hosted solution for
https://status.python.org/ but it’s not terribly difficult to migrate away from
that if we ever wanted to.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Benjamin Peterson 


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 CPython repo. Think repos like the PEPs repo,
> or the developer guide repo.
> 
> The primary objective of the PEP is to enable an online editing + pull
> request style workflow for these pure documentation projects that only
> have a single active branch.
> 
> 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 DVCS host's infrastructure,
> then reverting back to self-hosting (if that becomes necessary for
> some reason) is mostly just a matter of "hg push".
> 
> 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'd still be some work in such a change to make sure we didn't
> 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's
> repo as the initially proposed candidates for transfer.

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

Otherwise, moving the hosting will probably be more trouble
(administratively + infra) than it's worth.

I know it's hard to know, but do we have a lot of people comping at the
bit to submit PRs to the devguide repo?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Benjamin Peterson 


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 evening that in the age
> >> of DVCS's, that requirement may not make sense: if you avoid tightly
> >> coupling your automation to a particular DVCS host's infrastructure,
> >> then reverting back to self-hosting (if that becomes necessary for
> >> some reason) is mostly just a matter of "hg push".
> >> 
> >> 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.
> > 
> > For the record, I object to moving *official* PSF resources to proprietary,
> > closed-source infrastructure that we do not control or have access to[*].
> > 
> > As nice and friendly as BitBucket or any other code hosting source is today,
> > there are many reasons why I think this is a bad idea for *official*
> > branches.  We are beholden to their policies and operations, which may not
> > align with PSF policies or principles today or in the future.  We will not 
> > be
> > able to customize the experience for our own needs.  We will not have access
> > to the underlying resources should we need them for any purpose.  We cannot
> > take action ourselves if some problem occurs, e.g. banning an offensive 
> > user.
> > 
> > You're right that in a world of dvcs, branches can be mirrored anywhere.  
> > For
> > that reason, I have no problem allowing developers to use non-PSF controlled
> > resources *unofficially* if it makes their work easier and doesn't conflict
> > with their own principles.  However, in such cases, I still believe that the
> > official, master, blessed repositories remain on PSF controlled
> > infrastructure.  Surely that too is possible in the world of dvcs, right?
> > 
> > Cheers,
> > -Barry
> > 
> > [*] Please note that I am not objecting to our use of lower-level resources
> > donated by our generous sponsors.  It's a fine line perhaps, but I have no
> > problem with a wiki running on a VM hosted on some donated hardware, since 
> > we
> > still have full access to the machine, the OS, and the application software.
> 
> Personally I care less about proprietary and closed-source and care a lot
> more
> about lock-in. Thus my big problem using Bitbucket for these things is
> that if
> we ever want to *leave* bitbucket it becomes a lot harder because you
> have a
> bunch of links and such pointing at bitbucket instead of a python.org
> domain.
> They do offer a redirect feature but that is dependent on them not taking
> that
> away in the future. (They also offer a CNAME feature but if you use it
> you lose
> the ability to use TLS, which is also a non starter for me). Sadly this
> also
> leaves out my favorite host site of Github :/. Something like Github
> Enterprise
> or Atlassian stash which are able to be migrated away from are better in
> this
> regards.
> 
> Ironically we do use a propetiary/closed-source/hosted solution for
> https://status.python.org/ but it’s not terribly difficult to migrate
> away from
> that if we ever wanted to.

The more significant one is probably Fastly.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Chris Angelico 
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 well-known function - all you have is someone writing a generator
that calls next() in multiple places. Is it obvious that it it'll
silently terminate as soon as any one of those iterators is exhausted?
In many cases, an exception (probably ValueError?) would be the most
obvious response.

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Paul Moore 
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 obvious to every user that this will consume an element from
>> it1, then silently terminate if it2 no longer has any content?
>
> "Every user"? Of course not. But it should be obvious to those who think
> carefully about the specification of zip() and what is available to
> implement it.
>
> zip() can't detect that the second argument is empty except by calling
> next(), which it doesn't do until after it has retrieved a value from
> the first argument. If it turns out the second argument is empty, what
> can it do with that first value? It can't shove it back into the
> iterator. It can't return a single value, or pad it with some sentinel
> value (that's what izip_longest does). 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?

Interestingly, although I said "yes, it's obvious", I'd missed this
subtlety. But I don't consider it "unexpected" or a "gotcha", just
subtle. I certainly don't consider it to be the *wrong* behaviour - on
the contrary, I'd be more surprised to get a RuntimeError when the
second iterator was shorter.

What I understand to be the recommended alternative:

def izip(iterable1, iterable2):
it1 = iter(iterable1)
it2 = iter(iterable2)
while True:
try:
# Is it OK to cover both statements with one try...except?
# I think it should be, but it's a pattern I try to avoid
v1 = next(it1)
v2 = next(it2)
except StopIteration:
return
   yield v1, v2

looks less obvious to me, and obscures the intent a little.

(Note that I understand this is only one example and that others
present a much more compelling case in favour of the explicit return
form)

Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Ethan Furman 
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 [...]
> it1 = iter(iterable1)
> it2 = iter(iterable2)
> while True:
> v1 = next(it1)
> v2 = next(it2)
> yield v1, v2

Stepping back a little and looking at this code, sans header, let's consider 
the possible desired behaviors:

  - have an exact match-up between the two iterators, error otherwise
  - stop when one is exhausted
  - pad shorter one to longer one

Two of those three possible options are going to require dealing with the 
StopIteration that shouldn't escape -- is the
trade of keeping one option short and simple worth the pain caused by the 
error-at-a-distance bugs caused when a
StopIteration does escape that shouldn't have?

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Donald Stufft 

> 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.
>> 
>> Here is an example that I have taught for years:
>> 
>>def [...]
>>it1 = iter(iterable1)
>>it2 = iter(iterable2)
>>while True:
>>v1 = next(it1)
>>v2 = next(it2)
>>yield v1, v2
> 
> Stepping back a little and looking at this code, sans header, let's consider 
> the possible desired behaviors:
> 
>  - have an exact match-up between the two iterators, error otherwise
>  - stop when one is exhausted
>  - pad shorter one to longer one
> 
> Two of those three possible options are going to require dealing with the 
> StopIteration that shouldn't escape -- is the
> trade of keeping one option short and simple worth the pain caused by the 
> error-at-a-distance bugs caused when a
> StopIteration does escape that shouldn't have?
> 

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
it I wouldn't think about the fact that the next() calls can cause the
generator to terminate.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Antoine Pitrou 
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) SourceForge for open-source hg
> hosting.

I hope nobody's gonna suggest SourceForge seriously for anything. It's
the SharePoint (or Lotus Notes) of software forges.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Antoine Pitrou 
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 function.
> 
> Otherwise, moving the hosting will probably be more trouble
> (administratively + infra) than it's worth.
> 
> I know it's hard to know, but do we have a lot of people comping at the
> bit to submit PRs to the devguide repo?

People interested in the devguide are probably interested in CPython
core in the first place, so they'll have to accept hg anyway (or use a
git-hg bridge...).

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Chris Angelico 
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
> it I wouldn't think about the fact that the next() calls can cause the
> generator to terminate.

And don't forget, by the way, that you can always request the current
behaviour by explicitly wrapping the body of the function in
try/except:

def izip(iterable1, iterable2):
try:
it1 = iter(iterable1)
it2 = iter(iterable2)
while True:
v1 = next(it1)
v2 = next(it2)
yield v1, v2
except StopIteration:
pass

That's exactly what current behaviour does, and if you think that that
try block is too broad and should be narrowed, then you should support
this proposal :)

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Antoine Pitrou 
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 
> simpler and more direct way of creating iterators.  However, Chris explained 
> that, "This proposal causes a separation of generators and iterators, so it's 
> no longer possible to pretend that they're the same thing."  That is a major 
> and worrisome conceptual shift.

I agree with Raymond on this point.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Steve Dower 
> 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 CodePlex and (ironically) SourceForge for open-source hg
>> hosting.
> 
> I hope nobody's gonna suggest SourceForge seriously for anything. It's the
> SharePoint (or Lotus Notes) of software forges.

SourceForge can be Lotus Notes; CodePlex is SharePoint :-)

BitBucket is a much better option than either of those. Since I discovered 
hggit (and got it working), I'm less opposed to github than I have ever been, 
but I still prefer BitBucket. It just feels more pragmatic and less like a 
cattle market.

I'm not hugely for/against moving the repo, though I do like the general idea 
of reducing the amount of work committers have to do.

Cheers,
Steve

> Regards
> 
> Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2014-11-21 Thread Python tracker 

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 with patches: 2176 


Issues opened (30)
==

#22869: Split pylifecycle.c out from pythonrun.c
http://bugs.python.org/issue22869  reopened by pitrou

#22872: multiprocessing.Queue raises AssertionError
http://bugs.python.org/issue22872  opened by Joseph.Siddall

#22873: Re: SSLsocket.getpeercert - return ALL the fields of the certi
http://bugs.python.org/issue22873  opened by nagle

#22875: asyncio: call_soon() documentation unclear on timing
http://bugs.python.org/issue22875  opened by Corbin.Simpson

#22876: ip_interface can't be broadcast or number net
http://bugs.python.org/issue22876  opened by Вячеслав

#22881: show median in benchmark results
http://bugs.python.org/issue22881  opened by scoder

#22882: Document Linux packages you need to compile Python with all de
http://bugs.python.org/issue22882  opened by Ludovic.Gasc

#22883: Get rid of references to PyInt in Py3 sources
http://bugs.python.org/issue22883  opened by serhiy.storchaka

#22884: argparse.FileType.__call__ returns unwrapped sys.stdin and std
http://bugs.python.org/issue22884  opened by keviv

#22885: Arbitrary code execution vulnerability due to unchecked eval()
http://bugs.python.org/issue22885  opened by stephen.farris

#22886: TestProgram leaves defaultTestLoader.errors dirty
http://bugs.python.org/issue22886  opened by rbcollins

#22888: ensurepip and distutils' build_scripts fails on Windows when p
http://bugs.python.org/issue22888  opened by gmljosea

#22890: StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x
http://bugs.python.org/issue22890  opened by serhiy.storchaka

#22891: code removal from urllib.parse.urlsplit()
http://bugs.python.org/issue22891  opened by Alexander.Todorov

#22893: Idle: __future__ does not work in startup code.
http://bugs.python.org/issue22893  opened by terry.reedy

#22894: unittest.TestCase.subTest causes all subsequent tests to be sk
http://bugs.python.org/issue22894  opened by Trey.Cucco

#22895: test failure introduced by the fix for issue #22462
http://bugs.python.org/issue22895  opened by doko

#22896: Don't use PyObject_As*Buffer() functions
http://bugs.python.org/issue22896  opened by serhiy.storchaka

#22897: IDLE hangs on OS X with Cocoa Tk if encoding dialog is require
http://bugs.python.org/issue22897  opened by steipe

#22898: segfault during shutdown attempting to log ResourceWarning
http://bugs.python.org/issue22898  opened by emptysquare

#22899: http.server.BaseHTTPRequestHandler.parse_request (TypeError: d
http://bugs.python.org/issue22899  opened by recharti

#22901: test.test_uuid.test_find_mac fails because of `ifconfig` depre
http://bugs.python.org/issue22901  opened by bru

#22902: Use 'ip' for uuid.getnode()
http://bugs.python.org/issue22902  opened by bru

#22903: unittest creates non-picklable errors
http://bugs.python.org/issue22903  opened by pitrou

#22904: make profile-opt includes -fprofile* flags in _sysconfigdata C
http://bugs.python.org/issue22904  opened by gregory.p.smith

#22906: PEP 479: Change StopIteration handling inside generators
http://bugs.python.org/issue22906  opened by Rosuav

#22907: Misc/python-config.sh.in: ensure sed invocations only match be
http://bugs.python.org/issue22907  opened by peko

#22908: ZipExtFile in zipfile can be seekable
http://bugs.python.org/issue22908  opened by Iridium.Yang

#22909: [argparse] Using parse_known_args, unknown arg with space in v
http://bugs.python.org/issue22909  opened by TabAtkins

#22910: test_pydoc test_synopsis_sourceless is a flaky test
http://bugs.python.org/issue22910  opened by gregory.p.smith



Most recent 15 issues with no replies (15)
==

#22909: [argparse] Using parse_known_args, unknown arg with space in v
http://bugs.python.org/issue22909

#22907: Misc/python-config.sh.in: ensure sed invocations only match be
http://bugs.python.org/issue22907

#22896: Don't use PyObject_As*Buffer() functions
http://bugs.python.org/issue22896

#22893: Idle: __future__ does not work in startup code.
http://bugs.python.org/issue22893

#22890: StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x
http://bugs.python.org/issue22890

#22886: TestProgram leaves defaultTestLoader.errors dirty
http://bugs.python.org/issue22886

#22885: Arbitrary code execution vulnerability due to unchecked eval()
http://bugs.python.org/issue22885

#22883: Get rid of references to PyInt in Py3 sources
http://bugs.python.org/issue22883

#22872: multiprocessing.Queue raises AssertionError
http://bugs.python.org/issue22872

#22865: Allow pty.spawn to ignore data to copy
http://bugs.python.org/issue22865

#22859: unittest.TestProgram.usageExit no longer invoked
http://bugs.pyth

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

2014-11-21 Thread Steven D'Aprano 
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
> "clever" libraries).
> 
> I wonder if the PEP needs a better transition plan, e.g.
> 
> - right now, start an education campaign
> - with Python 3.5, introduce "from __future__ import generator_return", and
> silent deprecation warnings
> - with Python 3.6, start issuing non-silent deprecation warnings
> - with Python 3.7, make the new behavior the default (subject to some kind
> of review)

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, `return value` is a syntax error inside 
generators. Currently, the only way to handle this case in 2+3 code is 
by using `raise StopIteration(value)` but if that changes in 3.6 or 3.7 
then there will be no (obvious?) way to deal with this case.


-- 
Steven
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Guido van Rossum 
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 that a primary motivation for generators is to
> provide a simpler and more direct way of creating iterators.  However,
> Chris explained that, "This proposal causes a separation of generators and
> iterators, so it's no longer possible to pretend that they're the same
> thing."  That is a major and worrisome conceptual shift.
>
> I agree with Raymond on this point.
>

Pretending they're the same thing has always been fraught with subtle
errors. From the *calling* side a generator implements the same protocol as
any other iterator (though it also has a few others -- send(), throw(),
close()). However *inside* they are not at all similar -- generators
produce a value is done through "yield", __next__() methods use return.

Even if we end up rejecting the PEP we should campaign for better
understanding of generators. Raymond may just have to fix some of his
examples.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Guido van Rossum 
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, `return value` is a syntax error inside
> generators. Currently, the only way to handle this case in 2+3 code is
> by using `raise StopIteration(value)` but if that changes in 3.6 or 3.7
> then there will be no (obvious?) way to deal with this case.


Note that using StopIteration for this purpose is a recent invention (I
believe I invented it for the Google App Engine NDB library).

Before Python 3.3 this had to be essentially a private protocol implemented
by the framework, and typically the framework defines a custom exception
for this purpose -- either an alias for StopIteration, or a subclass of it,
or a separate exception altogether. I did a little survey:

- ndb uses "return Return(v)" where Return is an alias for StopIteration.

- monocle uses "yield Return(v)", so it doesn't even use an exception.

- In Twisted you write "returnValue(v)" -- IMO even more primitive since
it's not even a control flow statement.

- In Tornado you write "raise tornado.gen.Return(v)", where Return does not
inherit from StopIteration. In Python 3.3 and later you can also write
"return v", and the framework treats Return and StopIteration the same --
but there is no mention of "raise StopIteration(v)" in the docs and given
that they have Return there should be no need for it, ever.

- In Trollius (the backport of asyncio) you write "raise Return(v)", where
Return is currently a subclass of StopIteration -- but it doesn't really
have to be, it could be a different exception (like in Tornado).

So I haven't found any framework that recommends "raise StopIteration(v)".
Sure, some frameworks will have to be changed, but they have until Python
3.6 or 3.6, and the changes can be made to work all the way back to Python
2.7.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Guido van Rossum 
Like it or not, github is easily winning this race.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Ned Deily 
In article <[email protected]>,
 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 sense: if you avoid tightly
> >coupling your automation to a particular DVCS host's infrastructure,
> >then reverting back to self-hosting (if that becomes necessary for
> >some reason) is mostly just a matter of "hg push".
> >
> >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.
> 
> For the record, I object to moving *official* PSF resources to proprietary,
> closed-source infrastructure that we do not control or have access to[*].
> 
> As nice and friendly as BitBucket or any other code hosting source is today,
> there are many reasons why I think this is a bad idea for *official*
> branches.  We are beholden to their policies and operations, which may not
> align with PSF policies or principles today or in the future.  We will not be
> able to customize the experience for our own needs.  We will not have access
> to the underlying resources should we need them for any purpose.  We cannot
> take action ourselves if some problem occurs, e.g. banning an offensive user.
> 
> You're right that in a world of dvcs, branches can be mirrored anywhere.  For
> that reason, I have no problem allowing developers to use non-PSF controlled
> resources *unofficially* if it makes their work easier and doesn't conflict
> with their own principles.  However, in such cases, I still believe that the
> official, master, blessed repositories remain on PSF controlled
> infrastructure.  Surely that too is possible in the world of dvcs, right?

I agree with Barry's arguments.

Another issue, so to speak, is what to do about issues?  Bitbucket, 
Github, et al provide integrated issue trackers - like we do with the 
current hg.python.org / bugs.python.org integration.  If we were to move 
the official repos to another site, then what about the official site 
for issues?  If we don't move the issues as well, some of the power and 
advantages of using the third-party site are lost (no one-click moving 
between issues and source, etc.).  If we do move the issues, then we 
have a new source of confusion as to where people should open bugs 
(adding to the bug janitors workload), the problem of issue history 
(older and open issues in one tracker, newer ones in another), and a 
different workflow for tracking the issues.

bugs.python.org already supports a kind of pull request with the "Remote 
hg repo" field.  If the goal is to make it easier for newcomers to 
contribute via pull requests, perhaps that field could be better 
documented (like adding specific instructions to a readme on the 
Bitbucket read-only mirror) or improved, if necessary.

https://docs.python.org/devguide/triaging.html#mercurial-repository

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Donald Stufft 

> On Nov 21, 2014, at 3:04 PM, Ned Deily  wrote:
> 
> In article <[email protected]>,
> 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 sense: if you avoid tightly
>>> coupling your automation to a particular DVCS host's infrastructure,
>>> then reverting back to self-hosting (if that becomes necessary for
>>> some reason) is mostly just a matter of "hg push".
>>> 
>>> 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.
>> 
>> For the record, I object to moving *official* PSF resources to proprietary,
>> closed-source infrastructure that we do not control or have access to[*].
>> 
>> As nice and friendly as BitBucket or any other code hosting source is today,
>> there are many reasons why I think this is a bad idea for *official*
>> branches.  We are beholden to their policies and operations, which may not
>> align with PSF policies or principles today or in the future.  We will not be
>> able to customize the experience for our own needs.  We will not have access
>> to the underlying resources should we need them for any purpose.  We cannot
>> take action ourselves if some problem occurs, e.g. banning an offensive user.
>> 
>> You're right that in a world of dvcs, branches can be mirrored anywhere.  For
>> that reason, I have no problem allowing developers to use non-PSF controlled
>> resources *unofficially* if it makes their work easier and doesn't conflict
>> with their own principles.  However, in such cases, I still believe that the
>> official, master, blessed repositories remain on PSF controlled
>> infrastructure.  Surely that too is possible in the world of dvcs, right?
> 
> I agree with Barry's arguments.
> 
> Another issue, so to speak, is what to do about issues?  Bitbucket, 
> Github, et al provide integrated issue trackers - like we do with the 
> current hg.python.org / bugs.python.org integration.  If we were to move 
> the official repos to another site, then what about the official site 
> for issues?  If we don't move the issues as well, some of the power and 
> advantages of using the third-party site are lost (no one-click moving 
> between issues and source, etc.).  If we do move the issues, then we 
> have a new source of confusion as to where people should open bugs 
> (adding to the bug janitors workload), the problem of issue history 
> (older and open issues in one tracker, newer ones in another), and a 
> different workflow for tracking the issues.
> 
> bugs.python.org already supports a kind of pull request with the "Remote 
> hg repo" field.  If the goal is to make it easier for newcomers to 
> contribute via pull requests, perhaps that field could be better 
> documented (like adding specific instructions to a readme on the 
> Bitbucket read-only mirror) or improved, if necessary.
> 
> https://docs.python.org/devguide/triaging.html#mercurial-repository

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 creates a fork,
   and opens up a web based editor where I can make changes to
   that file.
3. I fill out the commit message and hit Save.
4. An automatic pull request is opened up with my changes.

I can submit a fix for a typo in the docs in like ~30 seconds assuming
I already have a Github account. That sort of instant win is a great
way to get people started contributing to a project and can lead later
to bigger more substantial contributions.

In contrast as a non core developer right now I have to:

1. Clone the hg repository
   A. Possibly this requires installing Mercurial and learning how to
  clone mercurial if I don’t already know how to do that.
2. Re-find the file and open it up in a text editor and make my changes.
3. Generate a patch
   A. Again this possibly involves figuring out how to create such a patch.
4. Create an issue on bugs.python.org describing the typo and upload my
   patch.

This would probably take me at least 10-15 minutes to do and I already know
the tooling involved well enough to do that much. If i wasn’t familiar that
could easily take hours in order to do a simple typo fix.

Isn’t much better on the core developer side either, assuming in both cases
that the patch is perfectly acceptable and you just need to merge it in, the
Github flow is:

1. Press big green merge button, rejoice.
2. Possibly manually merge into other branches
   - This can be done via PRs if you want as well, since you can make a PR that
 merges one branch into another via the web UI and press the big green
 button on that too.

The current

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

2014-11-21 Thread Ned Deily 
In article <[email protected]>,
 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 creates a fork,
>and opens up a web based editor where I can make changes to
>that file.
> 3. I fill out the commit message and hit Save.
> 4. An automatic pull request is opened up with my changes.
> 
> I can submit a fix for a typo in the docs in like ~30 seconds assuming
> I already have a Github account. That sort of instant win is a great
> way to get people started contributing to a project and can lead later
> to bigger more substantial contributions.
[...]
> Mostly what I’m trying to say is that documenting a field that essentially 
> requires
> the end user to not only figure out how to use mercurial, but figure out how 
> to
> host a public repository somewhere is not even really within the same order 
> of
> magnitude in ease of use.

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 of activity on those is quite 
small.  So, thinking about it a bit more, PEPs don't normally have bug 
tracker issues associated with them so I suppose my concerns about issue 
tracker aren't a major concern for them.  The dev guide does get issues 
opened about it and I suppose they could be managed.  But, without 
tackling the CPython repo workflow (a *much* bigger deal), is the 
divergence in workflows worth it?  I dunno.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Donald Stufft 

> On Nov 21, 2014, at 3:59 PM, Ned Deily  wrote:
> 
> In article <[email protected]>,
> 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 creates a fork,
>>   and opens up a web based editor where I can make changes to
>>   that file.
>> 3. I fill out the commit message and hit Save.
>> 4. An automatic pull request is opened up with my changes.
>> 
>> I can submit a fix for a typo in the docs in like ~30 seconds assuming
>> I already have a Github account. That sort of instant win is a great
>> way to get people started contributing to a project and can lead later
>> to bigger more substantial contributions.
> [...]
>> Mostly what I’m trying to say is that documenting a field that essentially 
>> requires
>> the end user to not only figure out how to use mercurial, but figure out how 
>> to
>> host a public repository somewhere is not even really within the same order 
>> of
>> magnitude in ease of use.
> 
> 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 of activity on those is quite 
> small.  So, thinking about it a bit more, PEPs don't normally have bug 
> tracker issues associated with them so I suppose my concerns about issue 
> tracker aren't a major concern for them.  The dev guide does get issues 
> opened about it and I suppose they could be managed.  But, without 
> tackling the CPython repo workflow (a *much* bigger deal), is the 
> divergence in workflows worth it?  I dunno.

Yea for the smaller repositories I don’t have a whole lot of opinion
about if the benefit buys us much, especially since one of the goals
is new-person friendliness but the problem is that it doesn’t translate
to contributing to CPython itself.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Support for Linux perf

2014-11-21 Thread Jonas Wagner 
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 that call
external commands. It would also be useful if you're interested in other
metrics than time (e.g., page faults).

Python does have support for profiling, though, in the cProfile module.

The cleanest solution for this might be to add some sort of plugin support
to Perf. Each plugin could teach Perf how to unwind a certain stack. I'm
thinking this because the problem is not specific to Python. Any
higher-level language would benefit from mapping the low-level instruction
pointer and C stack back to higher-level function calls. Databases might
use something like this to individual transactions or compiled SQL
queries...

These plugins would be quite closely tied to a particular interpreter
implementation. You only want them in certain circumstances, and it should
be possible to turn them off, e.g., when you want to profile the
interpreter itself.

On the other hand, this strays somewhat far from what Perf was designed
for. Maybe a custom stack walker could be more easily implemented in
something like SystemTap.

Best,
Jonas
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Tshepang Lekhonkhobe 
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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2014-11-21 Thread Guido van Rossum 
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 van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com