[Python-Dev] Re: [Release management] schedule for renaming the default branch

2021-03-11 Thread Victor Stinner
Hi Serhiy,

On Thu, Mar 11, 2021 at 8:33 AM Serhiy Storchaka  wrote:
> I have above 200 feature branches in my local repository. Will renaming
> the master branch cause any problems?

I don't think that you need to do anything on your machine nor on your open PRs.

When I use "git switch -c new_branch" command to create a new branch,
the created branch doesn't "track" its parent branch by default.
Example:

$ git branch -vv
(...)
* gilstate_init a6959b8971 bpo-43311: Create GIL autoTSSkey ealier
  master9a9c11ad41 [upstream/master] bpo-43287: Use PEP 590
vectorcall to speed up filter() (GH-24611)

My "gilstate_init" local branch doesn't track any branch, whereas my
local "master" branch tracks upstream/master (my upstream remote is
g...@github.com:python/cpython.git).

Usually, when I want to easily see the differences between a local
branch and my local master branch (to use my "git out" alias), I type
"git branch --set-upstream-to=master":

$ git switch gilstate_init
$ git branch --set-upstream-to=master
$ git out
a6959b8971 bpo-43311: Create GIL autoTSSkey ealier

where my "git out" alias is the command:

$ git log '@{upstream}..' --pretty='format:%Cred%h%Creset %s' --color --reverse

You can check that gilstate_init now tracks my local master branch:

$ git branch -vv
(...)
  gilstate_init a6959b8971 [master: ahead 1] bpo-43311: Create GIL
autoTSSkey ealier
  master9a9c11ad41 [upstream/master] bpo-43287: Use PEP 590
vectorcall to speed up filter() (GH-24611)

Use "git switch -c new_branch --track master" to create a new branch
based on master which tracks the master branch.

Maybe I should track upstream/master rather than my local master
branch, but when I fetch the upstream remote, I always update my local
master branch, so in my case, it's the same in pratice :-) And
"master" is shorter to type than "upstream/master".

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T7IS4WR5TTTI7ULDMH6JRQ7YTTJN7MID/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Release management] schedule for renaming the default branch

2021-03-11 Thread Pablo Galindo Salgado
> I have above 200 feature branches in my local > repository. Will renaming
> the master branch cause any problems?

It should not be any problem at all. If you have some open PRs from some of
those branches, they will be automatically retargeted to the new branch
name in GitHub automatically.

On Thu, 11 Mar 2021, 07:37 Serhiy Storchaka,  wrote:

> 10.03.21 16:06, Pablo Galindo Salgado пише:
> > # What you need to do?
> >
> > You just need to update your local clone after the branch name changes.
> > From the local clone of the repository on a computer,
> > run the following commands to update the name of the default branch.
> >
> > $ git branch -m master main
> > $ git fetch origin
> > $ git branch -u origin/main main
> >
> > Apart from that, you should update any local script or command that uses
> > the name "master" to use the name "main".
>
> I have above 200 feature branches in my local repository. Will renaming
> the master branch cause any problems?
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/G2LLBPJMIBD2DOA7AVTYYA77PGLGYLUE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6IVJZTCQ47F6MDBIF3UNY2DACHRBXHJO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Python history: origin of the arrow annotation

2021-03-11 Thread Shantanu Jain
Haskell and the MLs are older than I am and use "->" to mark their function
types (their functions are curried, but it clearly counts). Given the
overall influence functional languages have had on modern typing, their
influence making itself felt here would be unsurprising.

On Sat, 6 Mar 2021 at 07:47, Antoine Pitrou  wrote:

> On Fri, 5 Mar 2021 16:45:25 -0800
> Guido van Rossum  wrote:
>
> > Good question. I don't think anyone has ever asked this before... Given
> the
> > variants you propose, I'd say that the 3-character ones would be more
> > effort to type without real benefits, and `=>` would at the time (and
> > perhaps still :-) be seen as too close to `>=`.
> >
> > Could it be that there were already other languages using `->` for return
> > types? I do know that we needed something there -- from the start I was a
> > fan of `x: int` because it's the same as Pascal (the language I used most
> > intensely in college), and if it had been syntactically possible I would
> > have used 'def f(): int' for the return type as well, but the LL(1)
> parser
> > in use in 1999-2000 would interpret that as a very short function body.
> >
> > It's also possible that it comes from the `->` operator in C, which would
> > be the only "ASCII art arrow" that I was familiar with at the time.
>
> Note that nowadays you can use `->` to denote function return types in
> C++ (that was not the case in 1999, though).
> It's also the only allowed style for anonymous functions ("lambdas"):
> https://en.cppreference.com/w/cpp/language/function
> https://en.cppreference.com/w/cpp/language/lambda
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/K75WNUFDLY55FMYY5UID7EEEXWGNJZY3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ULU6EOEKPR7RQQ7VEHICIG6WBKBJ3KOI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Python history: origin of the arrow annotation

2021-03-11 Thread Nick Coghlan
On Fri, 5 Mar 2021, 9:10 pm Steven D'Aprano,  wrote:

> I was curious how and why return annotations use the arrow `->` symbol,
> so I went spelunking into the depths of the Python-Ideas and Python-Dev
> mailing lists.
>
> Much to my surprise, I couldn't find any discussion or debate about it.
>

If you haven't already, also try to track down any PEP 3107 discussions on
the python-3000 mailing list.

I don't actually recall any major debate over the syntax of function
annotations though - the only controversy I can recall was over whether or
not it was a good idea to add the syntax before we had a solid plan for the
standard associated semantics.

Cheers,
Nick.




>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5TGDHTV57GYJQDUOBW4WNZBMGXOQNCCQ/
Code of Conduct: http://python.org/psf/codeofconduct/