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

[Antoine Pitrou]

On Sat, 24 Jun 2017 21:37:46 -0700
Larry Hastings  wrote:
> On 06/24/2017 09:14 PM, Serhiy Storchaka wrote:
> > Not only core developers make PRs for CPython. Since all non-trivial 
> > changes need to be mentioned in Misc/NEWS, blurb becomes a required 
> > tool for all committers.  
> 
> Well, no.  *Writing blurb-compatible files* becomes a required step for 
> all committers.  And blurb makes that easy.  But it's pretty easy to 
> write them by hand; that's why we pre-created the "next" directories, 
> and there are instructions in the dev guide.

Hmm.  If it were so easy, you wouldn't have felt the need to add that
functionality to blurb, right? :-)

This is touching a more general problem, though.  Before GitHub, we
(core developers) would take the patch submitted by a contributor, make
whatever minor changes were needed (e.g. Misc/NEWS) and push the
aggregate ourselves.  With GitHub, while it's possible to edit someone
else's PR, it's frankly a PITA (I've tried to do it once, I don't want
to try a second time unless GitHub makes it massively easier and less
footgunning-prone). So we have to rely on contributors to make the PR
merge-ready by themselves... which means spending some time guiding
them through the oh-so-exciting steps necessary to add the right
Misc/NEWS entry, or fix the occasional bit of reStructuredText
mis-syntax.

Regards

Antoine.


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

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

[Paul Sokolovsky]

Hello,

On Sun, 25 Jun 2017 10:33:20 +0200
Antoine Pitrou  wrote:

[]

> Hmm.  If it were so easy, you wouldn't have felt the need to add that
> functionality to blurb, right? :-)
> 
> This is touching a more general problem, though.  Before GitHub, we
> (core developers) would take the patch submitted by a contributor,
> make whatever minor changes were needed (e.g. Misc/NEWS) and push the
> aggregate ourselves.  With GitHub, while it's possible to edit someone
> else's PR, it's frankly a PITA (I've tried to do it once, I don't want
> to try a second time unless GitHub makes it massively easier and less
> footgunning-prone).

Sorry, but how that can be true? A GitHub PR is just a git branch (in
somebody else's repository, but also in the repository it's submitted
to). So, like any git branch, you can fetch it, re-branch to your local
branch, apply any changes to it, rebase, push anywhere.

There're also various tools for dealing specifically with git branch
layout as used by Github, and every real man writes their own (because
it's easier to shoot a 5-liner than to review whether somebody else's
tool do what you need or not, it's all trivial git commands anyway).

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Sun, 25 Jun 2017 11:47:10 +0300
Paul Sokolovsky  wrote:
> > 
> > This is touching a more general problem, though.  Before GitHub, we
> > (core developers) would take the patch submitted by a contributor,
> > make whatever minor changes were needed (e.g. Misc/NEWS) and push the
> > aggregate ourselves.  With GitHub, while it's possible to edit someone
> > else's PR, it's frankly a PITA (I've tried to do it once, I don't want
> > to try a second time unless GitHub makes it massively easier and less
> > footgunning-prone).  
> 
> Sorry, but how that can be true? A GitHub PR is just a git branch [...]

Well, git usage can still be a PITA, at least for a non-neligible
proportion of its users.  I remember trying to push some changes to
someone else's PR, only to find that GitHub considered the PR had an
empty diff to master.  I'm not sure what produced it, but I have other
things to do than deal with obnoxious tooling (be it git or GitHub) on
my volunteer time.

So, my current policy with PRs where pushing changes would be
required is just to look elsewhere in the hope that another core
developer comes and deals with it ;-)

> There're also various tools for dealing specifically with git branch
> layout as used by Github, and every real man writes their own (because
> it's easier to shoot a 5-liner than to review whether somebody else's
> tool do what you need or not, it's all trivial git commands anyway).

I guess I'm not a "real man" who likes to "shoot 5-liners" made of
"trivial git commands" on my free time, then.  For some reason I'm not
even interested in becoming one.  The part of computing where people
posture as "real men" (or "wizards") by sequencing arcane commands on
ill-conceived UIs has always felt uninteresting and hostile to me.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

24.06.17 18:57, Larry Hastings пише:

On 06/24/2017 01:53 AM, Antoine Pitrou wrote:

Would you like to make it 3.5-compatible?  3.6 is quite young and not
all systems have it (e.g. Ubuntu 16.04, which many people use, has 3.5).


Well, tbh I think that's a bit silly.  First of all, it shouldn't be 
installed in your system-wide python3 interpreter.  Second, I assumed 
core devs were compiling their own Python interpreters locally in their 
account--in no small part so they can install any packages they want.  
And finally, you're asking me to give up f-strings.


If someone else wants to send me a PR getting it to work on 3.5, I'd 
look at it.  I'm guessing it's really just f-strings but I can't say for 
sure what else is a 3.6 dependency.


https://github.com/python/core-workflow/pull/143

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

[Python-Dev] __qualname__ format question

[Christian Tismer]

Hi friends,

by chance, I stumbled over

meth_get__qualname__

in methodobject.c and

calculate_qualname

in descrobject.c .

The first uses

res = PyUnicode_FromFormat("%S.%s", type_qualname, m->m_ml->ml_name);

and the latter uses

res = PyUnicode_FromFormat("%S.%S", type_qualname, descr->d_name);

To my knowledge, the "%S" character is undefined in C99 and C11.

Q: Why this character, and why this difference?

cheers - Chris
-- 
Christian Tismer :^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



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

Re: [Python-Dev] __qualname__ format question

[Serhiy Storchaka]

25.06.17 15:06, Christian Tismer пише:

by chance, I stumbled over

 meth_get__qualname__

in methodobject.c and

 calculate_qualname

in descrobject.c .

The first uses

 res = PyUnicode_FromFormat("%S.%s", type_qualname, m->m_ml->ml_name);

and the latter uses

 res = PyUnicode_FromFormat("%S.%S", type_qualname, descr->d_name);

To my knowledge, the "%S" character is undefined in C99 and C11.

Q: Why this character, and why this difference?


Se the documentation of PyUnicode_FromFormat().

https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_FromFormat

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

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

[Jakub Wilk]

* Paul Sokolovsky , 2017-06-25, 11:47:
A GitHub PR is just a git branch (in somebody else's repository, but also in 
the repository it's submitted to). So, like any git branch, you can fetch it, 
re-branch to your local branch, apply any changes to it, rebase, push 
anywhere.


Right, this is documented here:
https://help.github.com/articles/checking-out-pull-requests-locally/

There're also various tools for dealing specifically with git branch layout as 
used by Github, and every real man writes their own


I have this in my gitconfig:

[alias]
hub-pr = ! "_g() { set -e -u; git fetch origin \"pull/$1/head:gh-$1\" && git checkout 
\"gh-$1\"; }; _g"

If I want to checkout PR#42, I do:

$ git hub-pr 42

--
Jakub Wilk
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538 warning at startup: please remove it

[Terry Reedy]

On 6/12/2017 4:30 PM, Glenn Linderman wrote:

On 6/12/2017 1:11 PM, Terry Reedy wrote:
I do not have any locale-related env vars.  You should check whether 
the warning is off on all Win10 systems, as well as Win7 and Win8.  
Many Windows users know nothing about ENV VARS, and even if they do, 
they may not know how (I don't know the details) or MAY NOT BE ABLE to 
set one permanently. 


where (latest Win10): in the control panel, System and Security, System, 
Advanced system settings (left edge menu item),


On my system, accessing Advanced system settings requires an admin password.


Advanced Tab, Environment Variables (button).

Two sets of variables. User should always be able to set User variables 
that are in effect for all new processes launched after creation of the 
variable. 


On my auto-updated Win 10 system, one may only set User variables for 
the admin account one gave the password for.



System variables may be locked down if not administrator.


Are locked down.


Both types are permanent, stored in the registry.


As I said, I seem to only be able to do so permanently with admin access.

--
Terry Jan Reedy

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

Re: [Python-Dev] __qualname__ format question

[Christian Tismer]

On 25.06.17 14:41, Serhiy Storchaka wrote:
> 25.06.17 15:06, Christian Tismer пише:
>> by chance, I stumbled over
>>
>>  meth_get__qualname__
>>
>> in methodobject.c and
>>
>>  calculate_qualname
>>
>> in descrobject.c .
>>
>> The first uses
>>
>>  res = PyUnicode_FromFormat("%S.%s", type_qualname,
>> m->m_ml->ml_name);
>>
>> and the latter uses
>>
>>  res = PyUnicode_FromFormat("%S.%S", type_qualname, descr->d_name);
>>
>> To my knowledge, the "%S" character is undefined in C99 and C11.
>>
>> Q: Why this character, and why this difference?
> 
> Se the documentation of PyUnicode_FromFormat().
> 
> https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_FromFormat
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/tismer%40stackless.com

Ah, thank you very much.

Cheers - Chris

-- 
Christian Tismer :^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



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

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

[Chris Angelico]

On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou  wrote:
>> There're also various tools for dealing specifically with git branch
>> layout as used by Github, and every real man writes their own (because
>> it's easier to shoot a 5-liner than to review whether somebody else's
>> tool do what you need or not, it's all trivial git commands anyway).
>
> I guess I'm not a "real man" who likes to "shoot 5-liners" made of
> "trivial git commands" on my free time, then.  For some reason I'm not
> even interested in becoming one.  The part of computing where people
> posture as "real men" (or "wizards") by sequencing arcane commands on
> ill-conceived UIs has always felt uninteresting and hostile to me.

In the web programming bootcamp that I'm involved with, git is taught
in the very first week. It's not some arcane and hostile thing; the
command line is a fundamental tool that everyone is expected to become
friends with. The students learn about branching and merging
(including merge conflicts) and the pull-request workflow on the
second day of bootcamp.

Are we "real men" (and real women - we're not sexist here) because we
know how to type commands into a terminal? If so, we're making sure
the next generation of programmers is exclusively real men and women.

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

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

[Antoine Pitrou]

On Mon, 26 Jun 2017 01:27:20 +1000
Chris Angelico  wrote:
> On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou  wrote:
> >> There're also various tools for dealing specifically with git branch
> >> layout as used by Github, and every real man writes their own (because
> >> it's easier to shoot a 5-liner than to review whether somebody else's
> >> tool do what you need or not, it's all trivial git commands anyway).  
> >
> > I guess I'm not a "real man" who likes to "shoot 5-liners" made of
> > "trivial git commands" on my free time, then.  For some reason I'm not
> > even interested in becoming one.  The part of computing where people
> > posture as "real men" (or "wizards") by sequencing arcane commands on
> > ill-conceived UIs has always felt uninteresting and hostile to me.  
> 
> In the web programming bootcamp that I'm involved with, git is taught
> in the very first week. It's not some arcane and hostile thing; the
> command line is a fundamental tool that everyone is expected to become
> friends with. The students learn about branching and merging
> (including merge conflicts) and the pull-request workflow on the
> second day of bootcamp.
> 
> Are we "real men" (and real women - we're not sexist here) because we
> know how to type commands into a terminal?

The patronizing and not addressing the concrete issue at hand doesn't
make your opinion about "real men and women" very interesting to me,
sorry :-/

Regards

Antoine.


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

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

[Chris Angelico]

On Mon, Jun 26, 2017 at 1:52 AM, Antoine Pitrou  wrote:
> On Mon, 26 Jun 2017 01:27:20 +1000
> Chris Angelico  wrote:
>> On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou  wrote:
>> >> There're also various tools for dealing specifically with git branch
>> >> layout as used by Github, and every real man writes their own (because
>> >> it's easier to shoot a 5-liner than to review whether somebody else's
>> >> tool do what you need or not, it's all trivial git commands anyway).
>> >
>> > I guess I'm not a "real man" who likes to "shoot 5-liners" made of
>> > "trivial git commands" on my free time, then.  For some reason I'm not
>> > even interested in becoming one.  The part of computing where people
>> > posture as "real men" (or "wizards") by sequencing arcane commands on
>> > ill-conceived UIs has always felt uninteresting and hostile to me.
>>
>> In the web programming bootcamp that I'm involved with, git is taught
>> in the very first week. It's not some arcane and hostile thing; the
>> command line is a fundamental tool that everyone is expected to become
>> friends with. The students learn about branching and merging
>> (including merge conflicts) and the pull-request workflow on the
>> second day of bootcamp.
>>
>> Are we "real men" (and real women - we're not sexist here) because we
>> know how to type commands into a terminal?
>
> The patronizing and not addressing the concrete issue at hand doesn't
> make your opinion about "real men and women" very interesting to me,
> sorry :-/

My point is that EVERY developer needs to understand source control.
Since git is the dominant system these days, that basically means
everyone needs to understand git, although if you know (say) Mercurial
instead, that's adequate for 99% of situations (the other 1% being
where you're specifically collaborating on a git project). It's not
about some kind of supermen who know git, and everyone else who
doesn't. The command line is not an alternative to a GUI; it is
augmented by one. It is not "arcane" and "hostile"; it is a basic
fundamental of any sort of serious use of a computer.

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

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

[Stefan Krah]

On Sun, Jun 25, 2017 at 05:52:49PM +0200, Antoine Pitrou wrote:
> On Mon, 26 Jun 2017 01:27:20 +1000
> Chris Angelico  wrote:
> > In the web programming bootcamp that I'm involved with, git is taught
> > in the very first week. It's not some arcane and hostile thing; the
> > command line is a fundamental tool that everyone is expected to become
> > friends with. The students learn about branching and merging
> > (including merge conflicts) and the pull-request workflow on the
> > second day of bootcamp.
> > 
> > Are we "real men" (and real women - we're not sexist here) because we
> > know how to type commands into a terminal?
> 
> The patronizing and not addressing the concrete issue at hand doesn't
> make your opinion about "real men and women" very interesting to me,
> sorry :-/

Indeed, perhaps all core devs should take a course at this "web programming
bootcamp" (whatever that is), so we finally know how to use the command line. ;)

Linus should also attend the "bootcamp", so he can learn git and the command
line:

   https://github.com/torvalds/linux/pull/17#issuecomment-5654674



Stefan Krah



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

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

[Terry Reedy]

On 6/25/2017 8:06 AM, Serhiy Storchaka wrote:

24.06.17 18:57, Larry Hastings пише:

On 06/24/2017 01:53 AM, Antoine Pitrou wrote:

Would you like to make it 3.5-compatible?  3.6 is quite young and not
all systems have it (e.g. Ubuntu 16.04, which many people use, has 3.5).


Well, tbh I think that's a bit silly.  First of all, it shouldn't be 
installed in your system-wide python3 interpreter.  Second, I assumed 
core devs were compiling their own Python interpreters locally in 
their account--in no small part so they can install any packages they 
want. And finally, you're asking me to give up f-strings.


If someone else wants to send me a PR getting it to work on 3.5, I'd 
look at it.  I'm guessing it's really just f-strings but I can't say 
for sure what else is a 3.6 dependency.


https://github.com/python/core-workflow/pull/143


The diff amounts to regressing all f-strings back to %-strings.  If the 
patch is applied, an issue should be opened to revert it sometime in the 
future, such as when 3.7 is released.  But I really think we should be 
able to use currently released python to write tools to develop future 
releases.


My alternative proposal: modify the tooling so that one can install 
blurb, cherry_picker, and anything else into local cloned repositories 
without blocking proper use of git.  As near as I can tell, we just need 
to .gitignore Scripts/ and Lib/site-packages/, which are empty in the 
master repository.  Am I missing something?


F:\dev\3x>python -m ensurepip
Running Debug|Win32 interpreter...
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-9.0.1 setuptools-28.8.0

F:\dev\3x>git status
On branch pr_2377
Untracked files:
  (use "git add ..." to include in what will be committed)

Lib/site-packages/easy_install.py
Lib/site-packages/pip-9.0.1.dist-info/
Lib/site-packages/pip/
Lib/site-packages/pkg_resources/
Lib/site-packages/setuptools-28.8.0.dist-info/
Lib/site-packages/setuptools/
Scripts/

nothing added to commit but untracked files present (use "git add" to track)

F:\dev\3x>python -m pip install blurb
Running Debug|Win32 interpreter...
Collecting blurb
  Downloading blurb-1.0.0.post1-py3-none-any.whl (56kB)
100% || 61kB 596kB/s
Installing collected packages: blurb
Successfully installed blurb-1.0.0.post1

F:\dev\3x>python -m blurb
Running Debug|Win32 interpreter...


F:\dev\3x>git status
...
new file: 
Misc/NEWS.d/next/IDLE/2017-06-25-12-00-03.bpo-12345.2Oj8ot.rst


There it is, staged and ready to commit, with the message I entered 
('test'). (So, by the way, the revised blurb installer works.)


The same change should allow people to clone cpython and install and 
easily test other packages, such as numpy, with tip.


--
Terry Jan Reedy


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

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

[Terry Reedy]

On 6/25/2017 12:16 PM, Terry Reedy wrote:

On 6/25/2017 8:06 AM, Serhiy Storchaka wrote:

24.06.17 18:57, Larry Hastings пише:

On 06/24/2017 01:53 AM, Antoine Pitrou wrote:

Would you like to make it 3.5-compatible?  3.6 is quite young and not
all systems have it (e.g. Ubuntu 16.04, which many people use, has 
3.5).


Well, tbh I think that's a bit silly.  First of all, it shouldn't be 
installed in your system-wide python3 interpreter.  Second, I assumed 
core devs were compiling their own Python interpreters locally in 
their account--in no small part so they can install any packages they 
want. And finally, you're asking me to give up f-strings.


If someone else wants to send me a PR getting it to work on 3.5, I'd 
look at it.  I'm guessing it's really just f-strings but I can't say 
for sure what else is a 3.6 dependency.


https://github.com/python/core-workflow/pull/143


The diff amounts to regressing all f-strings back to %-strings.  If the 
patch is applied, an issue should be opened to revert it sometime in the 
future, such as when 3.7 is released.  But I really think we should be 
able to use currently released python to write tools to develop future 
releases.


My alternative proposal: modify the tooling so that one can install 
blurb, cherry_picker, and anything else into local cloned repositories 
without blocking proper use of git.  As near as I can tell, we just need 
to .gitignore Scripts/ and Lib/site-packages/, which are empty in the 
master repository.  Am I missing something?


The repository does not have an empty Scripts/ (and maybe this is 
Windows specific).  It does have Lib/site-packages.



F:\dev\3x>python -m ensurepip
Running Debug|Win32 interpreter...
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-9.0.1 setuptools-28.8.0

F:\dev\3x>git status
On branch pr_2377
Untracked files:
   (use "git add ..." to include in what will be committed)

 Lib/site-packages/easy_install.py
 Lib/site-packages/pip-9.0.1.dist-info/
 Lib/site-packages/pip/
 Lib/site-packages/pkg_resources/
 Lib/site-packages/setuptools-28.8.0.dist-info/
 Lib/site-packages/setuptools/
 Scripts/

nothing added to commit but untracked files present (use "git add" to 
track)


F:\dev\3x>python -m pip install blurb
Running Debug|Win32 interpreter...
Collecting blurb
   Downloading blurb-1.0.0.post1-py3-none-any.whl (56kB)
 100% || 61kB 596kB/s
Installing collected packages: blurb
Successfully installed blurb-1.0.0.post1


Removing added files is different from reverting changes to existing 
files.  To clean up, after running 'git clean -d -n', I ran

F:\dev\3x>git clean -d -f
Removing Lib/site-packages/blurb-1.0.0.post1.dist-info/
Removing Lib/site-packages/blurb.py
Removing Lib/site-packages/easy_install.py
Removing Lib/site-packages/pip-9.0.1.dist-info/
Removing Lib/site-packages/pip/
Removing Lib/site-packages/pkg_resources/
Removing Lib/site-packages/setuptools-28.8.0.dist-info/
Removing Lib/site-packages/setuptools/
Removing Misc/NEWS.d/next/IDLE/2017-06-25-12-00-03.bpo-12345.2Oj8ot.rst
Removing Scripts/

--
Terry Jan Reedy


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

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

[Brett Cannon]

On Sat, Jun 24, 2017, 23:45 Nick Coghlan,  wrote:

> On 25 June 2017 at 16:31, Terry Reedy  wrote:
> >> 25.06.17 06:04, Nick Coghlan пише:
> >>> All the PRs share an issue number in that case, so Bedevere should be
> >>> able to pick up that there's a pre-existing NEWS entry (even if it
> >>> isn't being added by that particular PR).
> >
> > You seem to be suggesting adding a possibly incomplete entry with the
> first
> > patch.  If that is so, it would be helpful if blurb could pull an
> existing
> > file for an issue into the editor.
>
> I was mainly referring to cases where either an initial commit (with a
> complete NEWS entry) requires follow-up fixes (no NEWS edit
> necessary).
>
> However, another case did occur to me, which is fixing bugs reported
> against never-released features (which is what I'm currently working
> on for PEP 538).
>

https://github.com/python/bedevere/pull/22 is the current implementation of
the check. All it does is see if the PR has a path that contains a news
file. It can also easily be changed to also support some "no news" label if
people want it to.


> So trying to automate that particular check may end up proving to be
> more hassle than it's worth.
>

The entire reason I want to have this check is I don't want or have to ask
another PR submitter to include a draft of a news item. It's much easier to
edit an existing news entry through the web UI than either ask for it and
deal with the turnaround time to get the PR submitter to add it.

-brett


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

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

[Nathaniel Smith]

On Jun 25, 2017 08:12, "Jakub Wilk"  wrote:

* Paul Sokolovsky , 2017-06-25, 11:47:

A GitHub PR is just a git branch (in somebody else's repository, but also
> in the repository it's submitted to). So, like any git branch, you can
> fetch it, re-branch to your local branch, apply any changes to it, rebase,
> push anywhere.
>

Right, this is documented here:
https://help.github.com/articles/checking-out-pull-requests-locally/


There're also various tools for dealing specifically with git branch layout
> as used by Github, and every real man writes their own
>

I have this in my gitconfig:

[alias]
hub-pr = ! "_g() { set -e -u; git fetch origin
\"pull/$1/head:gh-$1\" && git checkout \"gh-$1\"; }; _g"

If I want to checkout PR#42, I do:

$ git hub-pr 42


I believe you and Paul are missing the specific problem that Antoine was
talking about, which is: how can we easily make changes *to someone else's
PR*, i.e. these changes should show up in the diff view if you go to the
PR's web page. This requires not just getting a copy of the PR branch
locally, but also pushing it back to the original submitter's branch on
GitHub.

Allegedly this is possible in most cases (there's a permissions toggle the
submitter can set, but it's set by default):


https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/

However, like Antoine, when I've tried to do this then all I've managed is
to get obscure errors from GitHub. Did I have the wrong incantations? Was
the permissions toggle set wrong? (I thought the web ui said it wasn't, but
maybe I misunderstood.) It's a mystery. Has anyone figured out how to make
*this* work reliably or ergonomically?

Also, as a general comment, not directed at Jakub: the posturing about how
easy git is reminds me of the posturing about how much better language X is
than others described here: http://blog.aurynn.com/contempt-culture-2. My
dudes, in a previous life I helped invent distributed VCS, but I still get
confused by fiddly git BS just like everyone else. I know you probably
aren't meaning to go around telling people that they're not Real
Programmers because they get confused like me, but you are and it's not
kind; please stop.

-n
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

On 06/25/2017 01:33 AM, Antoine Pitrou wrote:

On Sat, 24 Jun 2017 21:37:46 -0700
Larry Hastings  wrote:

Well, no.  *Writing blurb-compatible files* becomes a required step for
all committers.  And blurb makes that easy.  But it's pretty easy to
write them by hand; that's why we pre-created the "next" directories,
and there are instructions in the dev guide.

Hmm.  If it were so easy, you wouldn't have felt the need to add that
functionality to blurb, right? :-)


No, I'm not contradicting myself.  It's easy enough to do without blurb, 
but blurb makes it effortless.


For core developers who are adding NEWS entries all the time, it's 
little enough burden to ask them to install an extra tool.  There were 
enough constraints on the process that asking people to continually do 
it by hand seemed worse.


For non-core developers who may have never contributed to CPython 
before, and are doing this for probably the one time in their lives, 
having instructions on a web page telling them how to name and format a 
special file is probably better than simply requiring them to install a 
special tool.


Again, it's my hope that someone can make a static web page, to be 
checked in to the Dev Guide, that uses JS wizardry to create a 
downloadable file for you.  Also it might work to hide a simple 
"blurb-add.py" in the CPython library so that users of 3.7+ don't need 
an external tool in order to simply add a NEWS item.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donald Stufft]

> On Jun 25, 2017, at 12:39 PM, Brett Cannon  wrote:
> 
> 
> 
> On Sat, Jun 24, 2017, 23:45 Nick Coghlan,  > wrote:
> On 25 June 2017 at 16:31, Terry Reedy  > wrote:
> >> 25.06.17 06:04, Nick Coghlan пише:
> >>> All the PRs share an issue number in that case, so Bedevere should be
> >>> able to pick up that there's a pre-existing NEWS entry (even if it
> >>> isn't being added by that particular PR).
> >
> > You seem to be suggesting adding a possibly incomplete entry with the first
> > patch.  If that is so, it would be helpful if blurb could pull an existing
> > file for an issue into the editor.
> 
> I was mainly referring to cases where either an initial commit (with a
> complete NEWS entry) requires follow-up fixes (no NEWS edit
> necessary).
> 
> However, another case did occur to me, which is fixing bugs reported
> against never-released features (which is what I'm currently working
> on for PEP 538).
> 
> https://github.com/python/bedevere/pull/22 
>  is the current implementation of 
> the check. All it does is see if the PR has a path that contains a news file. 
> It can also easily be changed to also support some "no news" label if people 
> want it to.
> 
> 
> So trying to automate that particular check may end up proving to be
> more hassle than it's worth.
> 
> The entire reason I want to have this check is I don't want or have to ask 
> another PR submitter to include a draft of a news item. It's much easier to 
> edit an existing news entry through the web UI than either ask for it and 
> deal with the turnaround time to get the PR submitter to add it.
> 


We’ve had a similar check on pip for awhile now and we’ve had no real 
complaints. The label to mark a change as not needing a news file is useful, we 
also let you add a empty news file marked as trivial for the PR authors to 
indicate that their change doesn’t deserve a news file entry. It has worked 
well so far and we’ve gotten better news file coverage then we previously had.


—
Donald Stufft



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

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

[Larry Hastings]

On 06/25/2017 10:02 AM, Nathaniel Smith wrote:
My dudes, in a previous life I helped invent distributed VCS, but I 
still get confused by fiddly git BS just like everyone else.


Really?  I thought Bitkeeper was out before the monotone project even 
started--and TeamWare had monotone beat by most of a decade. Not to 
downplay your achievements, but I don't think you "helped invent DVCS".  
Or did you work on Bitkeeper / TeamWare?



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donald Stufft]

> On Jun 25, 2017, at 1:02 PM, Nathaniel Smith  wrote:
> 
> However, like Antoine, when I've tried to do this then all I've managed is to 
> get obscure errors from GitHub. Did I have the wrong incantations? Was the 
> permissions toggle set wrong? (I thought the web ui said it wasn't, but maybe 
> I misunderstood.) It's a mystery. Has anyone figured out how to make *this* 
> work reliably or ergonomically?



I have used it. I don’t use it every day but I’ve never had it fail on me 
unless the contributor has unchecked the flag. I just ``git remote add  `` then checkout their branch, add more commits, and push 
to their branch.


—
Donald Stufft



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

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

[Nathaniel Smith]

On Jun 25, 2017 10:27, "Larry Hastings"  wrote:



On 06/25/2017 10:02 AM, Nathaniel Smith wrote:

My dudes, in a previous life I helped invent distributed VCS, but I still
get confused by fiddly git BS just like everyone else.


Really?  I thought Bitkeeper was out before the monotone project even
started--and TeamWare had monotone beat by most of a decade.  Not to
downplay your achievements, but I don't think you "helped invent DVCS".  Or
did you work on Bitkeeper / TeamWare?


If your response to the previous message is to send an email to all of
python-dev nitpicking credentials, then I think you missed the point...

(There are many projects that attempted to somehow combine the terms
"distributed" and "VCS", but nowadays the overwhelmingly dominant use of
that term is to refer to system designs in the monotone/git/hg lineage.
Perhaps I could have phrased it better; feel free to pretend I wrote a
several paragraph history tracing which systems influenced which instead. I
don't think any of this affects the actual point, which is that you can be
arbitrarily familiar with how a software system works and still be lost and
confused on a regular basis, so people should pay attention and try to
avoid making comments that imply this indicates some personal deficit in
the asker.)

((Maybe I should clarify that the reason I'm being cranky about this isn't
really on my or Antoine's behalf, but on behalf of anyone lurking and
thinking "oh, python-dev says I suck, I guess I'm not cut out to be a
python contributor".))

(((Though also I *would* genuinely appreciate it if anyone could explain
how to make GitHub do the thing I couldn't figure out. Probably it's
something silly and obvious...)))

-n
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

On 6/25/2017 12:39 PM, Brett Cannon wrote:

The entire reason I want to have this check is I don't want or have to 
ask another PR submitter to include a draft of a news item. It's much 
easier to edit an existing news entry through the web UI than either ask 
for it and deal with the turnaround time to get the PR submitter to add it.


I was not aware that PRs could be edited via a web UI and have no idea 
how.  I search a PR for something, searched the devguide index for 
'web', and searched 3 Lifecycle of a pull request.  Did I miss 
something.  Also, 6. Helping with Documentation should say something 
about submitting typo PRs via the web, if indeed that is possible yet.



--
Terry Jan Reedy

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

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

[Stefan Krah]

On Sun, Jun 25, 2017 at 10:02:44AM -0700, Nathaniel Smith wrote:
> https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/
> 
> However, like Antoine, when I've tried to do this then all I've managed is
> to get obscure errors from GitHub. Did I have the wrong incantations? Was
> the permissions toggle set wrong? (I thought the web ui said it wasn't, but
> maybe I misunderstood.) It's a mystery. Has anyone figured out how to make
> *this* work reliably or ergonomically?

I don't know either.  Adding .patch to the PR URL, downloading the thing,
editing as necessary and crediting the author in the commit message would
be much much faster.



Stefan Krah



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

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

[Larry Hastings]

On 06/25/2017 11:01 AM, Nathaniel Smith wrote:
On Jun 25, 2017 10:27, "Larry Hastings" > wrote:



On 06/25/2017 10:02 AM, Nathaniel Smith wrote:

My dudes, in a previous life I helped invent distributed VCS, but
I still get confused by fiddly git BS just like everyone else.


Really?  I thought Bitkeeper was out before the monotone project
even started--and TeamWare had monotone beat by most of a decade. 
Not to downplay your achievements, but I don't think you "helped

invent DVCS".  Or did you work on Bitkeeper / TeamWare?


If your response to the previous message is to send an email to all of 
python-dev nitpicking credentials, then I think you missed the point...


Actually, I agreed with the point, I just wanted you to clarify about 
your claimed bona fides here.  And I notice your reply was sent "to all 
of python-dev" and contained a lot of "nitpicking"; either this behavior 
is permissible or it isn't.


DVCSes were a conceptual breakthrough, and the people behind it deserve 
all the praise and admiration we can heap on them.  If you "helped 
invent" them--that's fantastic!  Thank you!  If you didn't, then it's 
misleading to claim that you did, so please don't.



Perhaps I could have phrased it better; feel free to pretend I wrote a 
several paragraph history tracing which systems influenced which instead.


I don't think that's necessary.  "I was a core developer on a DVCS" 
would have handily made your point--you deeply understand DVCSes from 
both a conceptual and practical perspective--while also being brief and 
(IIUC) 100% accurate.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

On Sun, 25 Jun 2017 20:38:51 +0200
Stefan Krah  wrote:
> On Sun, Jun 25, 2017 at 10:02:44AM -0700, Nathaniel Smith wrote:
> > https://help.github.com/articles/committing-changes-to-a-pull-request-branch-created-from-a-fork/
> > 
> > However, like Antoine, when I've tried to do this then all I've managed is
> > to get obscure errors from GitHub. Did I have the wrong incantations? Was
> > the permissions toggle set wrong? (I thought the web ui said it wasn't, but
> > maybe I misunderstood.) It's a mystery. Has anyone figured out how to make
> > *this* work reliably or ergonomically?  
> 
> I don't know either.  Adding .patch to the PR URL, downloading the thing,
> editing as necessary and crediting the author in the commit message would
> be much much faster.

I might do that as well (actually did on another project after I
borked an attempt to push to the submitter's branch). Of course it
doesn't work if your aim is to collaborate with the submitter, only if
you want to take over and apply some polish before pushing.

Regards

Antoine.


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

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

[Brett Cannon]

On Sun, Jun 25, 2017, 11:24 Terry Reedy,  wrote:

> On 6/25/2017 12:39 PM, Brett Cannon wrote:
>
> > The entire reason I want to have this check is I don't want or have to
> > ask another PR submitter to include a draft of a news item. It's much
> > easier to edit an existing news entry through the web UI than either ask
> > for it and deal with the turnaround time to get the PR submitter to add
> it.
>
> I was not aware that PRs could be edited via a web UI and have no idea
> how.  I search a PR for something, searched the devguide index for
> 'web', and searched 3 Lifecycle of a pull request.  Did I miss
> something.  Also, 6. Helping with Documentation should say something
> about submitting typo PRs via the web, if indeed that is possible yet.
>

You can edit anything via the web, it's just part of GitHub and so we have
not documented it explicitly to avoid just duplicating GitHub's own docs.

-brett



>
> --
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

On Sun, Jun 25, 2017 at 12:23 PM, Brett Cannon  wrote:

>
>
> On Sun, Jun 25, 2017, 11:24 Terry Reedy,  wrote:
>
>> On 6/25/2017 12:39 PM, Brett Cannon wrote:
>>
>> > The entire reason I want to have this check is I don't want or have to
>> > ask another PR submitter to include a draft of a news item. It's much
>> > easier to edit an existing news entry through the web UI than either ask
>> > for it and deal with the turnaround time to get the PR submitter to add
>> it.
>>
>> I was not aware that PRs could be edited via a web UI and have no idea
>> how.  I search a PR for something, searched the devguide index for
>> 'web', and searched 3 Lifecycle of a pull request.  Did I miss
>> something.  Also, 6. Helping with Documentation should say something
>> about submitting typo PRs via the web, if indeed that is possible yet.
>>
>
> You can edit anything via the web, it's just part of GitHub and so we have
> not documented it explicitly to avoid just duplicating GitHub's own docs.
>

If you're still not sure how, from the PR UI go to the "Files changed" tab
and click the "pencil" icon on the heading for the file you want to change.
The PR creator must have enabled this (but I think it's on by default).
When you save, GitHub creates a new commit in the PR's branch and all the
usual tests (Travis-CI etc.) get kicked off. Where it breaks down is if you
want to edit multiple files (it creates a new commit for each) or if the
files are large (scrolling around is awkward) or if you want to make
extensive changes (the web editor is limited in its capabilities, it's
based on https://codemirror.net/).

-- 
--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/python-dev/archive%40mail-archive.com

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

[Paul Moore]

On 25 June 2017 at 18:31, Donald Stufft  wrote:
>
> I have used it. I don’t use it every day but I’ve never had it fail on me
> unless the contributor has unchecked the flag. I just ``git remote add
>  `` then checkout their branch, add more
> commits, and push to their branch.

That's relatively simple, but not immediately obvious (at least to me).

There's a lot of concepts in here that are not exactly basic:

1. Being allowed to have multiple remotes in one repository
2. Naming of branches in non-default remotes, and how to translate the
name in the remote to the local name you need to use
3. Pushing to non-default remotes

There's also the point noted that by default, github doesn't permit
this usage, and the contributor has to explicitly allow it - which
probably means the core dev need to know how to do it, and how to
explain that process to the contributor.

And probably others. I'm not interested in debating what constitutes
stuff that "everyone should know", or how "easy" or not git is. But
for someone coming from a familiarity with Mercurial (which means many
core devs) the learning curve is pretty steep (I'd consider that
self-evident, because of the differences between the 2 systems).

The decision to move to git/github has been made. It's not up for
debate whether core devs need to learn to deal with it. But we do need
to acknowledge that there's a significant learning curve, and while
core devs are contributing from their free time, learning the new
tooling is a major distraction from what they actually want to do,
which is work on Python code.

I don't have a good solution, but I do think we need to acknowledge
the issue and address it without making judgements on what other
people are familiar with or not.

Paul

PS There's a *lot* of stuff going by in the core-workflow list - the
new blurb and cherry-picker tools, lots of workflow recommendations,
etc. I haven't even looked at most of them yet, which means I'm
accumulating an increasing load of work I can do before I get back to
the point where I can contribute (and I'm familiar with git). Finding
the time to pay off that debt is getting harder and harder...
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Oleg Broytman]

On Sun, Jun 25, 2017 at 10:39:36PM +0100, Paul Moore  
wrote:
> for someone coming from a familiarity with Mercurial (which means many
> core devs) the learning curve is pretty steep (I'd consider that

   I switched to git after had been using hg for about 3 years. The
first few months after the switch were rather painful. It took me a year
to start understanding git and another year to master it. But I'm a slow
thinker, I must admit.

> self-evident, because of the differences between the 2 systems).

   Not sure about self-evidence. At the first glance they look similar.
Both are DVCSes with DAG.
   The devil is in the details. In a lot of small quite different
details.

> Paul

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

On 26 June 2017 at 07:39, Paul Moore  wrote:

> On 25 June 2017 at 18:31, Donald Stufft  wrote:
> >
> > I have used it. I don’t use it every day but I’ve never had it fail on me
> > unless the contributor has unchecked the flag. I just ``git remote add
> >  `` then checkout their branch, add more
> > commits, and push to their branch.
>
> The decision to move to git/github has been made. It's not up for
> debate whether core devs need to learn to deal with it. But we do need
> to acknowledge that there's a significant learning curve, and while
> core devs are contributing from their free time, learning the new
> tooling is a major distraction from what they actually want to do,
> which is work on Python code.
>

I went  through this transition a few years ago when I changed employment
(and didn't enjoy it in the slightest). Coming from Mercurial, Git feels
primitive (I mean that literally - common functionality often requires
low-level, arcane invocations). I can keep all of the Mercurial
command-line that I use regularly in my head, whereas with Git I always
have to go back to the manual even for things that I use all the time, and
I'm often unsure if I'll get the result I expect. As a result, I've avoided
using Git directly as much as possible.

Instead, my personal recommendation for people who are experienced with
Mercurial but not Git is to use Mercurial with the hggit plugin. It's not
ideal, but since Mercurial functionality is almost a superset of Git
functionality, it works so long as you don't use things that Git can't
handle.

The most important things to be aware of IMO are:

1. Avoid the use of named branches and instead use bookmarks (a workflow I
personally hate, but it's the closest match to git branches, and I know I'm
an anomaly in preferring named branches).

2. Last I checked hggit can't force-push to a git repository after
history-modifying actions (e.g. rebase) so after such actions it's
necessary to delete any existing branch in a local git repo, hg push to
that then force-push to Github. This wnew branch head.

So the workflow I use for working with Github is (after enabling hggit):

git clone  .git
hg clone git+.git 

cd .hg
...

cd .git
git branch -d  

cd .hg
hg push -B  .git

cd .git
git push --force

Although I use a Git GUI to avoid having to remember the git commands ...

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

On 26 June 2017 at 08:20, Tim Delaney  wrote:

>
> 2. Last I checked hggit can't force-push to a git repository after
> history-modifying actions (e.g. rebase) so after such actions it's
> necessary to delete any existing branch in a local git repo, hg push to
> that then force-push to Github. This wnew branch head.
>

Not sure what happened there - that last line should have been:

This will update any PR for that branch to the new branch head.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538 warning at startup: please remove it

[Glenn Linderman]

On 6/25/2017 8:14 AM, Terry Reedy wrote:

On 6/12/2017 4:30 PM, Glenn Linderman wrote:

On 6/12/2017 1:11 PM, Terry Reedy wrote:
I do not have any locale-related env vars.  You should check whether 
the warning is off on all Win10 systems, as well as Win7 and Win8.  
Many Windows users know nothing about ENV VARS, and even if they do, 
they may not know how (I don't know the details) or MAY NOT BE ABLE 
to set one permanently. 


where (latest Win10): in the control panel, System and Security, 
System, Advanced system settings (left edge menu item),


On my system, accessing Advanced system settings requires an admin 
password.


Interesting and surprising. I guess you've concluded that my 
testing/reporting was from an admin account. Not only did I not get a 
request for an admin password, I did not get a confirmation dialog that 
I should proceed with admin access (like happens with installing 
programs, and running .reg files).





Advanced Tab, Environment Variables (button).

Two sets of variables. User should always be able to set User 
variables that are in effect for all new processes launched after 
creation of the variable. 


On my auto-updated Win 10 system, one may only set User variables for 
the admin account one gave the password for.


Interesting and surprising again.  User variables for the admin account, 
or user variables for the user account, once you achieve admin access.  
Perhaps the only way to discover the difference would be to create a 
new, junk variable when you get the dialog, and then reboot, and login 
as that user, and see if the variable persisted in user mode (can be 
seen by starting a CMD prompt, and doing set command).





System variables may be locked down if not administrator.


Are locked down.


Both types are permanent, stored in the registry.


As I said, I seem to only be able to do so permanently with admin access.



This seems extremely limiting.  User variables should be for the user, 
not the admin, and should be able to be set/saved by the user without 
having admin access. I wonder in what version of Windows this limitation 
was introduced... it is ridiculous, especially when people are preaching 
that you shouldn't need to run as admin all the time, for better 
security in Windows.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donald Stufft]

> On Jun 25, 2017, at 5:39 PM, Paul Moore  wrote:
> 
> On 25 June 2017 at 18:31, Donald Stufft  wrote:
>> 
>> I have used it. I don’t use it every day but I’ve never had it fail on me
>> unless the contributor has unchecked the flag. I just ``git remote add
>>  `` then checkout their branch, add more
>> commits, and push to their branch.
> 
> That's relatively simple, but not immediately obvious (at least to me).


I’m completely willing to agree that because git was the first VCS I used 
seriously (I tried Mercural out early on, but switched quickly before I got too 
deep in it b/c of Github) that my brain has successfully been broken in a git 
shaped way ;)


> 
> There's a lot of concepts in here that are not exactly basic:
> 
> 1. Being allowed to have multiple remotes in one repository
> 2. Naming of branches in non-default remotes, and how to translate the
> name in the remote to the local name you need to use
> 3. Pushing to non-default remotes
> 
> There's also the point noted that by default, github doesn't permit
> this usage, and the contributor has to explicitly allow it - which
> probably means the core dev need to know how to do it, and how to
> explain that process to the contributor.

Just a point of clarification, as far as I am aware Github defaults that 
checkmark to on, and PR authors have to explicitly turn it off to disable it. 
Although I think older PRs were all set to act as if the author did not grant 
that permission.

> 
> And probably others. I'm not interested in debating what constitutes
> stuff that "everyone should know", or how "easy" or not git is. But
> for someone coming from a familiarity with Mercurial (which means many
> core devs) the learning curve is pretty steep (I'd consider that
> self-evident, because of the differences between the 2 systems).


Not sure if this was aimed at me or not, but I don’t think that everyone should 
know that off the bat! I was just giving the steps I use to use it, hopefully 
in a useful way for other people.

—
Donald Stufft



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

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

[Nick Coghlan]

On 26 June 2017 at 02:39, Brett Cannon  wrote:
> On Sat, Jun 24, 2017, 23:45 Nick Coghlan,  wrote:
>> I was mainly referring to cases where either an initial commit (with a
>> complete NEWS entry) requires follow-up fixes (no NEWS edit
>> necessary).
>>
>> However, another case did occur to me, which is fixing bugs reported
>> against never-released features (which is what I'm currently working
>> on for PEP 538).
>
> https://github.com/python/bedevere/pull/22 is the current implementation of
> the check. All it does is see if the PR has a path that contains a news
> file. It can also easily be changed to also support some "no news" label if
> people want it to.

Yeah, I think I'd prefer to see the current "trivial" label split into
the more explicit "no issue needed" and "no NEWS needed". It isn't
necessarily the case that the changes in such PRs are trivial, it's
that the usual checks don't apply for some reason (and the change
being genuinely trivial is only one possibility)

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://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538 warning at startup: please remove it

[Nick Coghlan]

On 12 June 2017 at 22:24, Nick Coghlan  wrote:
> On 12 June 2017 at 18:56, Victor Stinner  wrote:
>> Hi,
>>
>> Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step
>> forward to UTF-8 everywhere ;-)
>>
>> I would prefer to not be annoyed by warning messages about encodings
>> at startup if possible:
>>
>> "Python detected LC_CTYPE=C: LC_CTYPE coerced to C.UTF-8 (set another
>> locale or PYTHONCOERCECLOCALE=0 to disable this locale coercion
>> behavior)."
>
> Note that there's an open issue for this linked from the What's New entry:
>
> * 
> https://docs.python.org/dev/whatsnew/3.7.html#pep-538-legacy-c-locale-coercion
> * https://bugs.python.org/issue30565
>
> I suspect the eventual outcome is going to be dropping that particular
> warning (since it's been problematic for Fedora's 3.6 backport as
> well, and the problems are due to the warning itself, *not* the locale
> coercion), but I'd prefer to keep the notification at least for a
> while (potentially even until alpha 1).
>
> OTOH, I'm also open to being persuaded otherwise if enough folks are
> running into problems with it just while working on CPython (I'd still
> like to turn it back on for alpha 1 even if we turn off in the
> meantime, though).

Following up here for the sake of folks following this thread, but not
all the related issues: with the locale warnings enabled by default,
we(/I) couldn't even get CPython's own test suite to pass reliably
across the full fleet of stable buildbots.

As a result, https://bugs.python.org/issue30565 was implemented in
https://github.com/python/cpython/pull/2260, switching us to an opt-in
warning model where you have to set `PYTHONCOERCECLOCALE=warn` to get
the notifications on stderr both when locale coercion triggers and
when the interpreter runtime itself is initialized in a locale that
would have triggered coercion in the CLI. That then becomes a runtime
debugging switch (akin to `-X faulthandler` or `-X tracemalloc`) for
folks investigating surprising locale-related behaviour in 3.7+,
rather than something we do by default.

The original PEP has also been updated with a note indicating that the
originally accepted approach was found to be impractical:
https://www.python.org/dev/peps/pep-0538/#implementation-notes

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://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

On 26 June 2017 at 07:39, Paul Moore  wrote:
> On 25 June 2017 at 18:31, Donald Stufft  wrote:
>>
>> I have used it. I don’t use it every day but I’ve never had it fail on me
>> unless the contributor has unchecked the flag. I just ``git remote add
>>  `` then checkout their branch, add more
>> commits, and push to their branch.
>
> That's relatively simple, but not immediately obvious (at least to me).

This seems like a good point to remind folks that we have a "Git
Bootcamp and Cheat Sheet" as part of the developer guide:
https://docs.python.org/devguide/gitbootcamp.html

PR editing is one of the topics covered:
https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging

However, many of us editing it tend to be on Linux or Mac OS X (and
are often experienced git users as well), so issues and PRs clarifying
steps that are currently omitted, platform-specific, or otherwise
don't work as advertised are definitely appreciated.

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://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com