[Nathaniel Smith ]
> ...
> As far as git is concerned, the main repo on github, your fork on
> github, and your local repo are 3 independent repositories, equally
> valid. The relationships between them are purely a matter of
> convention.
Thanks for that! It instantly cleared up several mysterie
On Tue, May 22, 2018 at 3:51 PM, Skip Montanaro
wrote:
>> You don't really need copies of official branches on your Github fork if
> you're not a maintainer for these branches.
>
> I explicitly wanted to run with 3.7 in the run-up to release. On that
> branch, the built ./python reports 3.7.0b4+ a
On May 22, 2018, at 18:51, Skip Montanaro wrote:
> [Ivan Pozdeev]:
>> You don't really need copies of official branches on your Github fork
>> if you're not a maintainer for these branches.
> I explicitly wanted to run with 3.7 in the run-up to release. On that
> branch, the built ./python reports
> You don't really need copies of official branches on your Github fork if
you're not a maintainer for these branches.
I explicitly wanted to run with 3.7 in the run-up to release. On that
branch, the built ./python reports 3.7.0b4+ at startup. Master tells me
3.8.0a0 on startup. Since my local re
On 22.05.2018 3:07, Skip Montanaro wrote:
My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch
was created. I have no remotes/origin/3.7. Is there some way to create it
from remotes/upstream/3.7? I asked on GitHub's help forums. The only
recommendation was to to delete my f
For the record: the only reason that I replied on GitHub was because the
proposal was not yet posted (as far as I know) to any mailing list.
Typically, a post is made to a mailing list more or less at the same
time as creating the PEP. In this case, there was a delay of a few days,
maybe also
On Tue, May 22, 2018 at 10:07 AM, Steve Dower
wrote:
> On 22May2018 0741, Guido van Rossum wrote:
>
>> ISTR there are plenty of PEPs that never get posted to python-ideas
>> because they are discussed on a separate list.
>>
>
> There are often better venues for the initial discussion (such as
> s
On 22 May 2018 at 18:00, Steve Dower wrote:
> On 21May2018 0708, Paul Moore wrote:
>>
>> On 21 May 2018 at 14:42, Serhiy Storchaka wrote:
Is it even acceptable to add a symbol into the limited ABI? I thought
the idea was that if I linked with python3.dll, my code would work
wi
On 5/22/2018 2:26 PM, Yury Selivanov wrote:
On Tue, May 22, 2018 at 8:52 AM Victor Stinner wrote:
Usually, I don't open a new bug to fix or enhance a test. So I
wouldn't say that it's mandatory. It's really on a case by case basis.
It seems like test_asyncio failures are a hot topic these d
On Tue, May 22, 2018 at 8:52 AM Victor Stinner wrote:
> Usually, I don't open a new bug to fix or enhance a test. So I
> wouldn't say that it's mandatory. It's really on a case by case basis.
> It seems like test_asyncio failures are a hot topic these days :-)
> It's one of the reasons why Pytho
On 5/22/2018 8:37 AM, Andrew Svetlov wrote:
Sorry for that.
I thought that the bpo issue can be skipped because it is tests-only
change, no asyncio code was affected.
Will be more accurate next time.
A new issue was not needed. Adding 'bpo-33531' would have been fine,
automatically linking t
On 22May2018 0741, Guido van Rossum wrote:
ISTR there are
plenty of PEPs that never get posted to python-ideas because they are
discussed on a separate list.
There are often better venues for the initial discussion (such as
security-sig, distutils-sig or datetime-sig), but I think that's
ort
On 21May2018 0708, Paul Moore wrote:
On 21 May 2018 at 14:42, Serhiy Storchaka wrote:
Is it even acceptable to add a symbol into the limited ABI? I thought
the idea was that if I linked with python3.dll, my code would work
with any version of Python 3? By introducing new symbols, code linked
wi
On Tue, May 22, 2018 at 5:29 AM, Victor Stinner wrote:
> 2018-05-19 11:15 GMT+02:00 mark :
> > The PEP can be viewed here:
> > https://github.com/python/peps/blob/master/pep-0576.rst
> > (...)
> > P.S.
> > I'm happy to have discussion of this PEP take place via GitHub,
> > rather than the mailing
Usually, I don't open a new bug to fix or enhance a test. So I
wouldn't say that it's mandatory. It's really on a case by case basis.
It seems like test_asyncio failures are a hot topic these days :-)
It's one of the reasons why Python 3.7rc1 has been delayed by 2 days,
no? :-)
Victor
2018-05-22
Sorry for that.
I thought that the bpo issue can be skipped because it is tests-only
change, no asyncio code was affected.
Will be more accurate next time.
On Tue, May 22, 2018 at 3:26 PM Victor Stinner wrote:
> Hi,
>
> In https://bugs.python.org/issue33531, Andrew Svetlov wrote "Fixed
> failed
Hi,
In https://bugs.python.org/issue33531, Andrew Svetlov wrote "Fixed
failed sendfile tests on Windows (at least I hope so)." without giving
any bpo number or a commit number. So I looked at latest commits and I
found:
---
commit e2537521916c5bf88fcf54d4654ff1bcd332be4a
Author: Andrew Svetlov
D
2018-05-19 11:15 GMT+02:00 mark :
> The PEP can be viewed here:
> https://github.com/python/peps/blob/master/pep-0576.rst
> (...)
> P.S.
> I'm happy to have discussion of this PEP take place via GitHub,
> rather than the mailing list, but I thought I would follow the conventional
> route for now.
18 matches
Mail list logo
