Re: [Python-Dev] GitHub migration scheduled for Friday
On Wed, Feb 8, 2017 at 8:52 AM, Senthil Kumaran wrote: > On Tue, Feb 7, 2017 at 11:38 PM, Victor Stinner > wrote: > > I know that different people have different expectation on GitHub. I > > would like to take the opportunity of migrating to Git to use the > > "author" and "committer" fields. If the author is set to the real > > author, the one who proposed the change on the bug tracker or someone > > else, we will be able to compute statistics on most active > > contributors to more easily detect them and promote them to core > > developers. > > > > What do you think? > > I am +1 to this idea. The intention behind this idea is also good one. > > * When the patches come from Github PRs, the contribution authors are > automatically tracked. The comitter would be merging the changes from > the authors. > > * When contribution comes via Patches/ or for many existing patches, > setting the author is a good idea. > > If we enable auto-PR creation, which was done by Anish as part of his GSoC we might be able to set the original author based on the github username associated with his user on bpo. But I'm guessing we need more work in this area ;) ___ 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] GitHub migration scheduled for Friday
Brett Cannon wrote: > Because other core devs wanted a linear history. This preference was very > strong to the point people were willing to forgo the Merge button in > GitHub's web UI to enforce it until GitHub added the squash merge support > for the Merge button. Actually, there's a third option - using *rebase and merge* [1] button. It does not produce a merge commit but preserves commits from the pull request. [1] https://help.github.com/articles/about-pull-request-merges/#rebase-and-merge-your-pull-request-commits On Thu, Feb 9, 2017 at 1:53 AM, Brett Cannon wrote: > > > On Wed, 8 Feb 2017 at 15:04 Victor Stinner wrote: >> >> 2017-02-08 23:42 GMT+01:00 Brett Cannon : >> > Don't forget we are doing squash merges, >> >> Ah, I didn't know. Why not using merges? > > > Because other core devs wanted a linear history. This preference was very > strong to the point people were willing to forgo the Merge button in > GitHub's web UI to enforce it until GitHub added the squash merge support > for the Merge button. This was decided over a year ago and documented in PEP > 512 as the decision made since I believe the beginning of that PEP. > > Now I know Victor was asking out of curiosity, but I'm going to ask nicely > now and then ignore later anyone who starts second-guessing my decisions at > this point as someone did as a follow-up to Victor's question. This process > has been discussed for over 2 years and PEP 512 has existed for over one > year. There has also been an open mailing list where I have held discussions > on various topics and people have been free to ask and participate on. Now > is not the time to start second-guessing things that have already been > decided and discussed to great length before we even have any experience > with the chosen workflow. > > The final stretch of this whole process has been going smoothly, so I'm > trying to ask nicely that everyone give me the benefit of the doubt and > assume everything has been thought out and there is a reason behind > everything before you choose to second-guess my decisions at the 11th hour. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ihor%40kalnytskyi.com > ___ 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] Deterministic builds of the interpreter
Hi, I'm attempting to make the builds of the Python interpreters for Nixpkgs [1] deterministic. In the case of Python 2.7 we have a patch [2] that fixes the timestamp used in .pyc files in case the env var `DETERMINISTIC_BUILD` is set. We also remove `wininst*.exe`. This works fine, although there are 4 small issues left [3]. Do you have any idea what is going on in these files that could make them indeterministic? For Python 3.x I disabled ensurepip, removed `wininst*.exe`, and modified `py_compile` to use `0` instead of `source_stats['mtime']`. The builds are not yet deterministic [4]. Any suggestions what could be fixed here? Kind regards, Freddy [1] https://github.com/NixOS/nixpkgs [2] https://github.com/NixOS/nixpkgs/blob/1da6775/pkgs/development/interpreters/python/cpython/2.7/deterministic-build.patch [3] https://github.com/NixOS/nixpkgs/issues/22570#issuecomment-278474082 [4] https://gist.github.com/anonymous/7cc147af6511dee2dc5a5b8d110f0e6b ___ 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] Deterministic builds of the interpreter
As reading [4], mtime is not 0. data = bytearray(MAGIC_NUMBER) data.extend(_w_long(mtime)) data.extend(_w_long(source_size)) data.extend(marshal.dumps(code)) First 4 bytes are magic. Next 4 bytes are mtime. │ │ │ │ -: 160d 0d0a 6b2e 9c58 6c21 e300 k..Xl!.. │ │ │ │ +: 160d 0d0a e631 9c58 6c21 e300 .1.Xl!.. mtime is 6b2e9c58 vs e6319c53 (little endian) maybe, you failed to use customized py_compile when building? On Thu, Feb 9, 2017 at 6:27 PM, Freddy Rietdijk wrote: > Hi, > > I'm attempting to make the builds of the Python interpreters for Nixpkgs [1] > deterministic. > > In the case of Python 2.7 we have a patch [2] that fixes the timestamp used > in .pyc files in case the env var `DETERMINISTIC_BUILD` is set. We also > remove `wininst*.exe`. This works fine, although there are 4 small issues > left [3]. Do you have any idea what is going on in these files that could > make them indeterministic? > > For Python 3.x I disabled ensurepip, removed `wininst*.exe`, and modified > `py_compile` to use `0` instead of `source_stats['mtime']`. The builds are > not yet deterministic [4]. Any suggestions what could be fixed here? > > Kind regards, > > Freddy > > > [1] https://github.com/NixOS/nixpkgs > [2] > https://github.com/NixOS/nixpkgs/blob/1da6775/pkgs/development/interpreters/python/cpython/2.7/deterministic-build.patch > [3] https://github.com/NixOS/nixpkgs/issues/22570#issuecomment-278474082 > [4] https://gist.github.com/anonymous/7cc147af6511dee2dc5a5b8d110f0e6b > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > ___ 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] Deterministic builds of the interpreter
Correct, that was an older version from before I patched `_bootstrap_external.py`. A more recent diff can be found at https://gist.github.com/anonymous/d40f24fd6b636ba40d345ff3f12a0aaa These all seem to be sets. On Thu, Feb 9, 2017 at 6:04 PM, INADA Naoki wrote: > As reading [4], mtime is not 0. > > data = bytearray(MAGIC_NUMBER) > data.extend(_w_long(mtime)) > data.extend(_w_long(source_size)) > data.extend(marshal.dumps(code)) > > First 4 bytes are magic. > Next 4 bytes are mtime. > > │ │ │ │ -: 160d 0d0a 6b2e 9c58 6c21 e300 k..Xl!.. > │ │ │ │ +: 160d 0d0a e631 9c58 6c21 e300 .1.Xl!.. > > mtime is 6b2e9c58 vs e6319c53 (little endian) > > maybe, you failed to use customized py_compile when building? > > > On Thu, Feb 9, 2017 at 6:27 PM, Freddy Rietdijk > wrote: > > Hi, > > > > I'm attempting to make the builds of the Python interpreters for Nixpkgs > [1] > > deterministic. > > > > In the case of Python 2.7 we have a patch [2] that fixes the timestamp > used > > in .pyc files in case the env var `DETERMINISTIC_BUILD` is set. We also > > remove `wininst*.exe`. This works fine, although there are 4 small issues > > left [3]. Do you have any idea what is going on in these files that could > > make them indeterministic? > > > > For Python 3.x I disabled ensurepip, removed `wininst*.exe`, and modified > > `py_compile` to use `0` instead of `source_stats['mtime']`. The builds > are > > not yet deterministic [4]. Any suggestions what could be fixed here? > > > > Kind regards, > > > > Freddy > > > > > > [1] https://github.com/NixOS/nixpkgs > > [2] > > https://github.com/NixOS/nixpkgs/blob/1da6775/pkgs/ > development/interpreters/python/cpython/2.7/deterministic-build.patch > > [3] https://github.com/NixOS/nixpkgs/issues/22570#issuecomment-278474082 > > [4] https://gist.github.com/anonymous/7cc147af6511dee2dc5a5b8d110f0e6b > > > > ___ > > Python-Dev mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/ > songofacandy%40gmail.com > > > ___ 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] Deterministic builds of the interpreter
On Fri, Feb 10, 2017 at 2:45 AM, Freddy Rietdijk wrote: > Correct, that was an older version from before I patched > `_bootstrap_external.py`. A more recent diff can be found at > > https://gist.github.com/anonymous/d40f24fd6b636ba40d345ff3f12a0aaa > > These all seem to be sets. Maybe, PYTHONHASHSEED help you. https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED > > On Thu, Feb 9, 2017 at 6:04 PM, INADA Naoki wrote: >> >> As reading [4], mtime is not 0. >> >> data = bytearray(MAGIC_NUMBER) >> data.extend(_w_long(mtime)) >> data.extend(_w_long(source_size)) >> data.extend(marshal.dumps(code)) >> >> First 4 bytes are magic. >> Next 4 bytes are mtime. >> >> │ │ │ │ -: 160d 0d0a 6b2e 9c58 6c21 e300 >> k..Xl!.. >> │ │ │ │ +: 160d 0d0a e631 9c58 6c21 e300 >> .1.Xl!.. >> >> mtime is 6b2e9c58 vs e6319c53 (little endian) >> >> maybe, you failed to use customized py_compile when building? >> >> >> On Thu, Feb 9, 2017 at 6:27 PM, Freddy Rietdijk >> wrote: >> > Hi, >> > >> > I'm attempting to make the builds of the Python interpreters for Nixpkgs >> > [1] >> > deterministic. >> > >> > In the case of Python 2.7 we have a patch [2] that fixes the timestamp >> > used >> > in .pyc files in case the env var `DETERMINISTIC_BUILD` is set. We also >> > remove `wininst*.exe`. This works fine, although there are 4 small >> > issues >> > left [3]. Do you have any idea what is going on in these files that >> > could >> > make them indeterministic? >> > >> > For Python 3.x I disabled ensurepip, removed `wininst*.exe`, and >> > modified >> > `py_compile` to use `0` instead of `source_stats['mtime']`. The builds >> > are >> > not yet deterministic [4]. Any suggestions what could be fixed here? >> > >> > Kind regards, >> > >> > Freddy >> > >> > >> > [1] https://github.com/NixOS/nixpkgs >> > [2] >> > >> > https://github.com/NixOS/nixpkgs/blob/1da6775/pkgs/development/interpreters/python/cpython/2.7/deterministic-build.patch >> > [3] https://github.com/NixOS/nixpkgs/issues/22570#issuecomment-278474082 >> > [4] https://gist.github.com/anonymous/7cc147af6511dee2dc5a5b8d110f0e6b >> > >> > ___ >> > Python-Dev mailing list >> > [email protected] >> > https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > >> > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com >> > > > ___ 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] "format" builtin function, docstring improvement
Dear python developpers,
First I'd like to thank you for your work, you're making the world simple !
Then I would like to share a very light suggestion for the improvement of python, I hope I am using the right way for this.
(I am using python 3.4.3)
I am from the science side, more precisely physics, and I often have to display or log formatted numbers during computations.
Usually I have numbers with many digits and it is necessary for me to use the right format for display (for setting the number of digits after coma, for using exponent notation, etc...) I was using the way of the "%" until I found the __builtins__.format function.
But I still cannot remember all the letters for the possible options, such as presented in the part named "7.1.3.1. Format Specification Mini-Language" of this page :
https://docs.python.org/2/library/string.html
And each time I need to remind of the mini-language, I need to open a web-page or a file and it is breaking my workflow.
So I think it would be helpful that the "format.__doc__" string would contains a quick example showing the way to set the number of digits, the appearance conditions of the signs as well as a quick reminder of the "Mini-language" types.
I have made a template of the docstring to begin with, that I send as an attached file, but I am not familiar with docstring format.
Also, there is maybe more material to add to the docstring that will be likely to help other people the same way.
I hope you like the idea,
Yours sincerely,
Hugo Prod'homme.
>>> 'number is : {:03.2f}'.format(2)
'number is : 2.00'
>>> 'number is : {:03.2f}'.format(2.3555)
'number is : 2.36'
>>> '{:+f}; {:+f}'.format(3.14, -3.14) # show it always
'+3.14; -3.14'
>>> '{: f}; {: f}'.format(3.14, -3.14) # show a space for positive numbers
' 3.14; -3.14'
>>> '{:-f}; {:-f}'.format(3.14, -3.14) # show only the minus -- same as '{:f};
>>> {:f}'
'3.14; -3.14'
"b" : Binary format.
"c" : Character.
"d" : Decimal Integer.
"e" : Exponent notation.
"E" : Exponent notation, upper case 'E'.
"f" : Fixed point
"F" : Fixed point. Same as 'f'.
"g" : General format.
"G" : General format, switches to 'E' if the number gets too large. The
representations of infinity and NaN are uppercased, too.
"n" : Number. This is the same as 'g', except that it uses the current locale
setting to insert the appropriate number separator characters.
"o" : Octal format.
"s" : String format.
"x" : Hex format, using lower- case letters for the digits above 9.
"X" : Hex format, using upper- case letters for the digits above 9.
"%" : Percentage.
None : Thesame as 'g'.
___
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] "format" builtin function, docstring improvement
On Thu, Feb 9, 2017 at 1:18 PM, Hugo PROD HOMME wrote: > > I have made a template of the docstring to begin with, that I send as an attached file, but I am not familiar with docstring format. Please open an issue at bugs.python.org. We did something similar in issue #9650, [1] so I think this will be well received. Python docstrings are in plain text, but you need to consult PEP 436 (The Argument Clinic DSL) [2] for details. The format() docstring is specified in Python/bltinmodule.c. [1]: http://bugs.python.org/issue9650 [2]: https://www.python.org/dev/peps/pep-0436/#function-docstring ___ 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
