Re: [Python-Dev] Asking for reversion

[Ronald Oussoren via Python-Dev]

> On 4 Feb 2019, at 04:25, Davin Potts  
> wrote:
> 
> On 2/3/2019 7:55 PM, Guido van Rossum wrote:
> > Also, did anyone ask Davin directly to roll it back?
> 
> Simply put:  no.  There have been a number of reactionary comments in the 
> last 16 hours but no attempt to reach out to me directly during that time.
> 

I asked a question about the commit yesterday night in the tracker and was 
waiting for a response (which I fully expected to take some time due to 
timezone differences and this being a volunteer driven project). 

Ronald
___
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] Asking for reversion

[Antoine Pitrou]

On Sun, 3 Feb 2019 21:25:27 -0600
Davin Potts  wrote:
> On 2/3/2019 7:55 PM, Guido van Rossum wrote:
> > Also, did anyone ask Davin directly to roll it back?  
> 
> Simply put:  no.  There have been a number of reactionary comments in the
> last 16 hours but no attempt to reach out to me directly during that time.

By construction, if I post a comment on an issue you opened yourself on
the bug tracker, you are receiving those comments.

I'm not sure why a private message would be necessary.  Generally, we
refrain from doing things in private except if there are personal
issues.

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] Asking for reversion

[Antoine Pitrou]

On Sun, 3 Feb 2019 17:52:55 -0800
Raymond Hettinger  wrote:
> > On Feb 3, 2019, at 1:03 PM, Antoine Pitrou  wrote:
> > 
> > I'd like to ask for the reversion of the changes done in
> > https://github.com/python/cpython/pull/11664  
> 
> Please work *with* Davin on this one.

You know, Raymond, I'm a volunteer and I dedicate my time to whatever I
want.  If someone pushes some unfinished work, it is perfectly normal
to ask for reversion instead of feeling obliged to finish the work
myself.

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] Asking for reversion

[Antoine Pitrou]

On Sun, 3 Feb 2019 18:10:43 -0800
Raymond Hettinger  wrote:
> > On Feb 3, 2019, at 5:40 PM, Terry Reedy  wrote:
> > 
> > On 2/3/2019 7:55 PM, Guido van Rossum wrote:  
> >> Also, did anyone ask Davin directly to roll it back?  
> > 
> > Antoine posted on the issue, along with Robert O.  Robert reviewed and make 
> > several suggestions.  
> 
> I think the PR sat in a stable state for many months, 

According to Github, it was opened 11 days ago.
The first commit itself is 12 days old (again according to Github):
https://github.com/python/cpython/pull/11664/commits/90f4a6cb2da8e187fa38b05c3f347cd602dd69c5

Now, perhaps the work itself is much older.

But regardless, you cannot expect someone to take notice of a PR or
issue if they are not put in CC.  It is very much against our usual
conventions to check in large pieces of code without asking anyone for
review.

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] Asking for reversion

[Antoine Pitrou]

On Sun, 3 Feb 2019 21:12:38 -0600
Davin Potts  wrote:
> 
> I was encouraged by Lukasz, Yury, and others to check in this code early,
> not waiting for tests and docs, in order to both solicit more feedback and
> provide for broader testing.

For the record: submitting a PR without tests or docs is perfectly
fine, and a reasonable way to ask for feedback.  Merging that PR is
not, usually (especially as you didn't wait for feedback).

So there might have been a misunderstanding between you and
Lukasz, Yury and the "others".  Or perhaps this is another instance of
taking a disruptive decision in private...

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] Asking for reversion

[Łukasz Langa]

> On 4 Feb 2019, at 01:49, Guido van Rossum  wrote:
> 
> I think this is now up to the 3.8 release manager.

I responded on the tracker: https://bugs.python.org/issue35813#msg334817

I wrote:

> @Davin, in what time can you fill in the missing tests and documentation?  If 
> this is something you finish do before alpha2, I'm inclined to leave the 
> change in.
> 
> As it stands, I missed the controversy yesterday as I was busy making my 
> first release.  So the merge *got released* in alpha1.  I would prefer to fix 
> the missing pieces forward instead of reverting and re-submitting which will 
> only thrash blame and history at this point.
> 
> FTR, I do agree with Antoine, Ronald and others that in the future such big 
> changes should be as close to their ready state at merge time.



@Raymond, would you be willing to work with Davin on finishing this work in 
time for alpha2?


- Ł


signature.asc
Description: Message signed with OpenPGP
___
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] About multiprocessing maintainership

[Antoine Pitrou]

Hello,

In a recent message, Raymond dramatically pretends that I would have
"edited out" Davin of the maintainers list for the multiprocessing
module.

What I did (*) is different: I asked to mark Davin inactive and to stop
auto-assigning him on bug tracker issues.  Davin was /still/ listed in
the experts list, along with me and others.  IOW, there was no "editing
out".

(*) https://github.com/python/devguide/pull/435

The reason I did this is simple: Davin does not do, and has almost
never done, any actual maintenance work on multiprocessing (if you are
not convinced, just go through the git history, and the PRs that were
merged in the ~4 last years).  He usually does not respond to tracker
issues opened by users.  He does not review PRs.  The only sizable
piece of work he committed is, as I mentioned in the previous thread,
still untested and undocumented.

Auto-assigning someone who never (AFAICT) responds to issues ultimately
does a disservice to users, whose complaints go unanswered; while other
people, who /do/ respond to users, are not aware of those stale issues.

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

[Python-Dev] Why a merge for 3.8.0a1?

[Stephane Wirtel]

Hi all,

After a git pull, I have seen there is a merge for v3.8.0a1 by Łukasz
Langa, why? I think the code should keep a linear commit and in this
case, it's against the "commit&squash" of CPython and Github :/

Thank you for your response.

Stéphane

--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
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] Why a merge for 3.8.0a1?

[Łukasz Langa]

> On 4 Feb 2019, at 11:58, Stephane Wirtel  wrote:
> 
> Hi all,
> 
> After a git pull, I have seen there is a merge for v3.8.0a1 by Łukasz
> Langa, why? I think the code should keep a linear commit and in this
> case, it's against the "commit&squash" of CPython and Github :/
> 
> Thank you for your response.

Tagging a release is different from a regular PR in the sense that you want the 
commit hash that you tagged as a given version to *remain the same*. In the 
mean time, other developers can (and will!) merge pull requests. If you were to 
rebase *the release tag* over their changes, the commit hash wouldn't match 
anymore. If you were to rebase *their changes* over your release tag, you'd 
have to force-push to update their changes.

This is described in PEP 101.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
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] [RELEASE] Python 3.8.0a1 is now available for testing

[Łukasz Langa]

I packaged my first release. *wipes sweat off of face*

Go get it here:
https://www.python.org/downloads/release/python-380a1/

Python 3.8.0a1 is the first of four planned alpha releases of Python 3.8,
the next feature release of Python.  During the alpha phase, Python 3.8
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.  The next preview release, 3.8.0a2, is planned
for 2019-02-24.

Apart from building the Mac installers, Ned helped me a lot with the
process, thank you!  Ernest was super quick providing me with all
required access and fixing a Unicode problem I found in Salt,
thank you!

Finally, this release was made on a train to Düsseldorf. There's a PyPy
sprint there. The train is pretty cool, makes this "Wasm! Wasm!" sound.

- Ł



signature.asc
Description: Message signed with OpenPGP
___
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] Why a merge for 3.8.0a1?

[Stephane Wirtel]

On 02/04, Łukasz Langa wrote:



On 4 Feb 2019, at 11:58, Stephane Wirtel  wrote:

Hi all,

After a git pull, I have seen there is a merge for v3.8.0a1 by Łukasz
Langa, why? I think the code should keep a linear commit and in this
case, it's against the "commit&squash" of CPython and Github :/

Thank you for your response.


Tagging a release is different from a regular PR in the sense that you want the 
commit hash that you tagged as a given version to *remain the same*. In the 
mean time, other developers can (and will!) merge pull requests. If you were to 
rebase *the release tag* over their changes, the commit hash wouldn't match 
anymore. If you were to rebase *their changes* over your release tag, you'd 
have to force-push to update their changes.

This is described in PEP 101.

- Ł


Hi Łukasz,

Thank you for this explanation and I have checked the PEP 101 and also
the way for 3.7 and there is also a merge.

Thanks, today, I have learned one thing.

Have a nice day,

PS: Really sorry for this bad ping but I wanted to have an explanation.

Stéphane



--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
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] [RELEASE] Python 3.8.0a1 is now available for testing

[Stephane Wirtel]

On 02/04, Łukasz Langa wrote:

I packaged my first release. *wipes sweat off of face*

Go get it here:
https://www.python.org/downloads/release/python-380a1/

Python 3.8.0a1 is the first of four planned alpha releases of Python 3.8,
the next feature release of Python.  During the alpha phase, Python 3.8
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.  The next preview release, 3.8.0a2, is planned
for 2019-02-24.

Apart from building the Mac installers, Ned helped me a lot with the
process, thank you!  Ernest was super quick providing me with all
required access and fixing a Unicode problem I found in Salt,
thank you!

Finally, this release was made on a train to Düsseldorf. There's a PyPy
sprint there. The train is pretty cool, makes this "Wasm! Wasm!" sound.

- Ł



Hi Lukasz,

Just one idea, we could create a Docker image with this alpha version.

This Docker image could be used with the CI of the main projects and the
test suites of these projects.

If we have some issues, we should create an issue for python 3.8.0a1.

Good idea?

Have a nice day,

Stéphane

--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
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] [RELEASE] Python 3.8.0a1 is now available for testing

[Stephane Wirtel]

It's unofficial but I used the Dockerfile for 3.7 and created this
Docker image:  


https://cloud.docker.com/u/matrixise/repository/docker/matrixise/python

docker pull matrixise/python:3.8.0a1

I am not an expert about the releasing of a Docker image but we could
work with that and try to improve it.

If one person use Gitlab-CI, this person can add a new test for this
version and use this image (matrixise/python:3.8.0a1) or an official
image, just for the tests...

Stéphane


--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
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] [RELEASE] Python 3.8.0a1 is now available for testing

[Stephane Wirtel]

On 02/04, Stephane Wirtel wrote:

It's unofficial but I used the Dockerfile for 3.7 and created this
Docker image:

https://cloud.docker.com/u/matrixise/repository/docker/matrixise/python

Sorry: here is the right link

https://hub.docker.com/r/matrixise/python


--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
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] Return type of datetime subclasses added to timedelta

[Paul Ganssle]

Hey all,

This thread about the return type of datetime operations seems to have
stopped without any explicit decision - I think I responded to everyone
who had objections, but I think only Guido has given a +1 to whether or
not we should go ahead.

Have we got agreement to go ahead with this change? Are we still
targeting Python 3.8 here?

For those who don't want to dig through your old e-mails, here's the
archive link for this thread:
https://mail.python.org/pipermail/python-dev/2019-January/155984.html

If you want to start commenting on the actual implementation, it's
available here (though it's pretty simple):
https://github.com/python/cpython/pull/10902

Best,

Paul


On 1/6/19 7:17 PM, Guido van Rossum wrote:
> OK, I concede your point (and indeed I only tested this on 3.6). If we
> could break the backward compatibility for now() we presumably can
> break it for this purpose.
>
> On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle  > wrote:
>
> I did address this in the original post - the assumption that the
> subclass constructor will have the same arguments as the base
> constructor is baked into many alternate constructors of datetime.
> I acknowledge that this is a breaking change, but it is a small
> one - anyone creating such a subclass that /cannot/ handled the
> class being created this way would be broken in myriad ways.
>
> We have also in recent years changed several alternate
> constructors (including `replace`) to retain the original
> subclass, which by your same standard would be a breaking change.
> I believe there have been no complaints. In fact, between Python
> 3.6 and 3.7, the very example you showed broke:
>
> Python 3.6.6:
>
> >>> class D(datetime.datetime):
> ... def __new__(cls):
> ... return cls.now()
> ...
> >>> D()
> D(2019, 1, 6, 13, 49, 38, 842033)
>
> Python 3.7.2:
>
> >>> class D(datetime.datetime):
> ... def __new__(cls):
> ... return cls.now()
> ...
> >>> D()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in __new__
> TypeError: __new__() takes 1 positional argument but 9 were given
>
>
> We haven't seen any bug reports about this sort of thing; what we
> /have/ been getting is bug reports that subclassing datetime
> doesn't retain the subclass in various ways (because people /are/
> using datetime subclasses). This is likely to cause very little in
> the way of problems, but it will improve convenience for people
> making datetime subclasses and almost certainly performance for
> people using them (e.g. pendulum and arrow, which now need to take
> a slow pure python route in many situations to work around this
> problem).
>
> If we're /really/ concerned with this backward compatibility
> breaking, we could do the equivalent of:
>
> try:
>     return new_behavior(...)
> except TypeError:
>     warnings.warn("The semantics of timedelta addition have "
>   "changed in a way that raises an error in "
>   "this subclass. Please implement __add__ "
>   "if you need the old behavior.", DeprecationWarning)
>
> Then after a suitable notice period drop the warning and turn it
> to a hard error.
>
> Best,
>
> Paul
>
> On 1/6/19 1:43 PM, Guido van Rossum wrote:
>> I don't think datetime and builtins like int necessarily need to
>> be aligned. But I do see a problem -- the __new__ and __init__
>> methods defined in the subclass (if any) should allow for being
>> called with the same signature as the base datetime class.
>> Currently you can have a subclass of datetime whose __new__ has
>> no arguments (or, more realistically, interprets its arguments
>> differently). Instances of such a class can still be added to a
>> timedelta. The proposal would cause this to break (since such an
>> addition has to create a new instance, which calls __new__ and
>> __init__). Since this is a backwards incompatibility, I don't see
>> how it can be done -- and I also don't see many use cases, so I
>> think it's not worth pursuing further.
>>
>> Note that the same problem already happens with the
>> .fromordinal() class method, though it doesn't happen with
>> .fromdatetime() or .now():
>>
>> >>> class D(datetime.datetime):
>> ...   def __new__(cls): return cls.now()
>> ...
>> >>> D()
>> D(2019, 1, 6, 10, 33, 37, 161606)
>> >>> D.fromordinal(100)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: __new__() takes 1 positional argument but 4 were given
>> >>> D.fromtimestamp(123456789)
>> D(1973, 11, 29, 13, 33, 9)
>> >>>
>>
>> On Sun, Jan 6, 2019 at 9:05 AM Paul Ganssle > > wrote:
>>
>> I can think 

Re: [Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

[Stephane Wirtel]

Hi Łukasz,

I have some issues with pytest and this release, you can see this BPO

https://bugs.python.org/issue35895

Have a nice day and thank you for your job.

Stéphane

--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
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] About multiprocessing maintainership

[Davin Potts]

Antoine's change to the devguide was made on the basis that "he doesn't
contribute anymore" which, going by Antoine's own description in this
thread, he contradicts.

My current effort, mentioned in Antoine's other thread, is not my single
largest contribution.  I have been impressed by the volume of time that
Antoine is able to spend on the issue tracker. Because he and I generally
agree on what actions to take on an issue, when he is quick to jump on
issues it is uncommon for me to feel the need to say something myself just
to play a numbers game or to make my presence felt -- that's part of being
a team.  There have been incidents where I disagree with Antoine and
explain the reasoning in an issue but later Antoine goes on to do whatever
he wants, disregarding what I wrote -- because I am not in a position to
necessarily react or respond as frequently, I've generally only discovered
this much later.  I regard this latter interaction as unhealthy.

I have been part of several group discussions (among core developers) now
regarding how to balance the efforts of contributors with copious time to
devote versus those which must be extra judicious in how they spend their
more limited time.  We recognize this as an ongoing concern and here it is
again.  If we are supportive of one another, we can find a way to work
through such things.

I joined the core developer team to help others and give back especially
when it involved the then-neglected multiprocessing module.  When I am
personally attacked in a discussion on an issue by someone I do not know,
it hurts and demoralizes me -- I know that all of the core developers
experience this.  When I am spending time on multiprocessing only to be
surprised by a claim that I don't contribute anymore, it hurts and
demoralizes me.  When I read hand-picked statistics to support a slanted
narrative designed to belittle my contributions, it hurts and demoralizes
me.  I know different people react to such things differently but in my
case I have occasionally needed to take time away from cpython to detox --
in 2018, such incidents led to my losing more than a month of time more
than once.

Regarding support for one another:  At the core developer sprint last year,
I volunteered to remotely host Antoine on my laptop so that he could
video-conference into the governance discussions we were having there.  A
few weeks later, Antoine is "editing me out" of the maintainers list
without any further communication.  If we only let the loudest people
contribute then we lose the quiet contributors and push them out.



Davin



On Mon, Feb 4, 2019 at 4:39 AM Antoine Pitrou  wrote:

>
> Hello,
>
> In a recent message, Raymond dramatically pretends that I would have
> "edited out" Davin of the maintainers list for the multiprocessing
> module.
>
> What I did (*) is different: I asked to mark Davin inactive and to stop
> auto-assigning him on bug tracker issues.  Davin was /still/ listed in
> the experts list, along with me and others.  IOW, there was no "editing
> out".
>
> (*) https://github.com/python/devguide/pull/435
>
> The reason I did this is simple: Davin does not do, and has almost
> never done, any actual maintenance work on multiprocessing (if you are
> not convinced, just go through the git history, and the PRs that were
> merged in the ~4 last years).  He usually does not respond to tracker
> issues opened by users.  He does not review PRs.  The only sizable
> piece of work he committed is, as I mentioned in the previous thread,
> still untested and undocumented.
>
> Auto-assigning someone who never (AFAICT) responds to issues ultimately
> does a disservice to users, whose complaints go unanswered; while other
> people, who /do/ respond to users, are not aware of those stale issues.
>
> 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/python%2Bpython_dev%40discontinuity.net
>
___
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] About multiprocessing maintainership

[Zachary Ware]

On Mon, Feb 4, 2019 at 4:39 AM Antoine Pitrou  wrote:
> What I did (*) is different: I asked to mark Davin inactive and to stop
> auto-assigning him on bug tracker issues.  Davin was /still/ listed in
> the experts list, along with me and others.  IOW, there was no "editing
> out".

Auto-assignment (and auto-add-to-nosy-list, for that matter) is
handled by the "components" of the bug tracker, see
bugs.python.org/component.  The experts list is used just for
populating the auto-completion for the nosy-list (that is, typing
"multi" in the nosy list entry field brings up "multiprocessing:
davin,pitrou" currently).  Marking a dev as "(inactive)" in the
experts list removes them from that auto-completion.

We've long discussed the possibility of rearranging how bpo does
auto-nosy/auto-assign such that a reporter can tag the affected
module(s) and auto-nosy based on the experts list.  That would take
significant effort which probably isn't worth doing unless PEP581
winds up rejected, but in the meantime we could easily add a
`multiprocessing` component that does whatever auto-nosy and/or
auto-assignment we want.

-- 
Zach
___
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] About multiprocessing maintainership

[Antoine Pitrou]

Hello Davin,

I would like this discussion to be constructive and not vindicative.  So
I would ask that we leave personal attacks out of this.

> I have been part of several group discussions (among core developers)
> now regarding how to balance the efforts of contributors with copious
> time to devote versus those which must be extra judicious in how they
> spend their more limited time.

It is a misconception to think that I would have "copious time" to
devote to the bug tracker and general contribution work.  I don't.

Actually, I find I am not responsive enough on such issues when they
fall in my areas of expertise.  For users and contributors, it is
generally demotivating to have to wait several weeks before a response
comes.

> A few weeks later, Antoine is "editing me out" of the
> maintainers list without any further communication.

You haven't been "edited out".  You were left in the maintainers list
(really an "experts list"), together with Richard Oudkirk who is the
original author of multiprocessing, but also Jesse Noller and me.

Again, I have found that frequently multiprocessing issues get
neglected.  This is in part because you are auto-assigned on such
issues, and therefore users and other contributors think you'll deal
with the issues, which you don't.

I could not guess by myself that you have been busy working in private
on a feature for the past 1.5 years.  So by all accounts you definitely
seemed to be "inactive" as far as multiprocessing maintenance goes.

My concern is to improve the likelihood of users getting a response on
multiprocessing issues.  One important factor is to be honest to users
who is actually available to respond to issues.

If you have another suggestion as to how act on this, please do.

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] Return type of datetime subclasses added to timedelta

[Guido van Rossum]

I recommend that you submit a PR so we can get it into 3.8 alpha 2.

On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle  wrote:

> Hey all,
>
> This thread about the return type of datetime operations seems to have
> stopped without any explicit decision - I think I responded to everyone who
> had objections, but I think only Guido has given a +1 to whether or not we
> should go ahead.
>
> Have we got agreement to go ahead with this change? Are we still targeting
> Python 3.8 here?
>
> For those who don't want to dig through your old e-mails, here's the
> archive link for this thread:
> https://mail.python.org/pipermail/python-dev/2019-January/155984.html
>
> If you want to start commenting on the actual implementation, it's
> available here (though it's pretty simple):
> https://github.com/python/cpython/pull/10902
>
> Best,
>
> Paul
>
>
> On 1/6/19 7:17 PM, Guido van Rossum wrote:
>
> OK, I concede your point (and indeed I only tested this on 3.6). If we
> could break the backward compatibility for now() we presumably can break it
> for this purpose.
>
> On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle  wrote:
>
>> I did address this in the original post - the assumption that the
>> subclass constructor will have the same arguments as the base constructor
>> is baked into many alternate constructors of datetime. I acknowledge that
>> this is a breaking change, but it is a small one - anyone creating such a
>> subclass that *cannot* handled the class being created this way would be
>> broken in myriad ways.
>>
>> We have also in recent years changed several alternate constructors
>> (including `replace`) to retain the original subclass, which by your same
>> standard would be a breaking change. I believe there have been no
>> complaints. In fact, between Python 3.6 and 3.7, the very example you
>> showed broke:
>>
>> Python 3.6.6:
>>
>> >>> class D(datetime.datetime):
>> ... def __new__(cls):
>> ... return cls.now()
>> ...
>> >>> D()
>> D(2019, 1, 6, 13, 49, 38, 842033)
>>
>> Python 3.7.2:
>>
>> >>> class D(datetime.datetime):
>> ... def __new__(cls):
>> ... return cls.now()
>> ...
>> >>> D()
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "", line 3, in __new__
>> TypeError: __new__() takes 1 positional argument but 9 were given
>>
>>
>> We haven't seen any bug reports about this sort of thing; what we *have*
>> been getting is bug reports that subclassing datetime doesn't retain the
>> subclass in various ways (because people *are* using datetime
>> subclasses). This is likely to cause very little in the way of problems,
>> but it will improve convenience for people making datetime subclasses and
>> almost certainly performance for people using them (e.g. pendulum and
>> arrow, which now need to take a slow pure python route in many situations
>> to work around this problem).
>>
>> If we're *really* concerned with this backward compatibility breaking,
>> we could do the equivalent of:
>>
>> try:
>> return new_behavior(...)
>> except TypeError:
>> warnings.warn("The semantics of timedelta addition have "
>>   "changed in a way that raises an error in "
>>   "this subclass. Please implement __add__ "
>>   "if you need the old behavior.", DeprecationWarning)
>>
>> Then after a suitable notice period drop the warning and turn it to a
>> hard error.
>>
>> Best,
>>
>> Paul
>> On 1/6/19 1:43 PM, Guido van Rossum wrote:
>>
>> I don't think datetime and builtins like int necessarily need to be
>> aligned. But I do see a problem -- the __new__ and __init__ methods defined
>> in the subclass (if any) should allow for being called with the same
>> signature as the base datetime class. Currently you can have a subclass of
>> datetime whose __new__ has no arguments (or, more realistically, interprets
>> its arguments differently). Instances of such a class can still be added to
>> a timedelta. The proposal would cause this to break (since such an addition
>> has to create a new instance, which calls __new__ and __init__). Since this
>> is a backwards incompatibility, I don't see how it can be done -- and I
>> also don't see many use cases, so I think it's not worth pursuing further.
>>
>> Note that the same problem already happens with the .fromordinal() class
>> method, though it doesn't happen with .fromdatetime() or .now():
>>
>> >>> class D(datetime.datetime):
>> ...   def __new__(cls): return cls.now()
>> ...
>> >>> D()
>> D(2019, 1, 6, 10, 33, 37, 161606)
>> >>> D.fromordinal(100)
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: __new__() takes 1 positional argument but 4 were given
>> >>> D.fromtimestamp(123456789)
>> D(1973, 11, 29, 13, 33, 9)
>> >>>
>>
>> On Sun, Jan 6, 2019 at 9:05 AM Paul Ganssle  wrote:
>>
>>> I can think of many reasons why datetime is different from builtins,
>>> though to be honest I'm not sure that consistency for its own sake is
>>> really a strong argument for 

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

[Paul Ganssle]

There's already a PR, actually, #10902:
https://github.com/python/cpython/pull/10902

Victor reviewed and approved it, I think before I started this thread,
so now it's just waiting on merge.

On 2/4/19 11:38 AM, Guido van Rossum wrote:
> I recommend that you submit a PR so we can get it into 3.8 alpha 2.
>
> On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle  > wrote:
>
> Hey all,
>
> This thread about the return type of datetime operations seems to
> have stopped without any explicit decision - I think I responded
> to everyone who had objections, but I think only Guido has given a
> +1 to whether or not we should go ahead.
>
> Have we got agreement to go ahead with this change? Are we still
> targeting Python 3.8 here?
>
> For those who don't want to dig through your old e-mails, here's
> the archive link for this thread:
> https://mail.python.org/pipermail/python-dev/2019-January/155984.html
>
> If you want to start commenting on the actual implementation, it's
> available here (though it's pretty simple):
> https://github.com/python/cpython/pull/10902
>
> Best,
>
> Paul
>
>
> On 1/6/19 7:17 PM, Guido van Rossum wrote:
>> OK, I concede your point (and indeed I only tested this on 3.6).
>> If we could break the backward compatibility for now() we
>> presumably can break it for this purpose.
>>
>> On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle > > wrote:
>>
>> I did address this in the original post - the assumption that
>> the subclass constructor will have the same arguments as the
>> base constructor is baked into many alternate constructors of
>> datetime. I acknowledge that this is a breaking change, but
>> it is a small one - anyone creating such a subclass that
>> /cannot/ handled the class being created this way would be
>> broken in myriad ways.
>>
>> We have also in recent years changed several alternate
>> constructors (including `replace`) to retain the original
>> subclass, which by your same standard would be a breaking
>> change. I believe there have been no complaints. In fact,
>> between Python 3.6 and 3.7, the very example you showed broke:
>>
>> Python 3.6.6:
>>
>> >>> class D(datetime.datetime):
>> ... def __new__(cls):
>> ... return cls.now()
>> ...
>> >>> D()
>> D(2019, 1, 6, 13, 49, 38, 842033)
>>
>> Python 3.7.2:
>>
>> >>> class D(datetime.datetime):
>> ... def __new__(cls):
>> ... return cls.now()
>> ...
>> >>> D()
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "", line 3, in __new__
>> TypeError: __new__() takes 1 positional argument but 9 were given
>>
>>
>> We haven't seen any bug reports about this sort of thing;
>> what we /have/ been getting is bug reports that subclassing
>> datetime doesn't retain the subclass in various ways (because
>> people /are/ using datetime subclasses). This is likely to
>> cause very little in the way of problems, but it will improve
>> convenience for people making datetime subclasses and almost
>> certainly performance for people using them (e.g. pendulum
>> and arrow, which now need to take a slow pure python route in
>> many situations to work around this problem).
>>
>> If we're /really/ concerned with this backward compatibility
>> breaking, we could do the equivalent of:
>>
>> try:
>>     return new_behavior(...)
>> except TypeError:
>>     warnings.warn("The semantics of timedelta addition have "
>>   "changed in a way that raises an error in "
>>   "this subclass. Please implement __add__ "
>>   "if you need the old behavior.",
>> DeprecationWarning)
>>
>> Then after a suitable notice period drop the warning and turn
>> it to a hard error.
>>
>> Best,
>>
>> Paul
>>
>> On 1/6/19 1:43 PM, Guido van Rossum wrote:
>>> I don't think datetime and builtins like int necessarily
>>> need to be aligned. But I do see a problem -- the __new__
>>> and __init__ methods defined in the subclass (if any) should
>>> allow for being called with the same signature as the base
>>> datetime class. Currently you can have a subclass of
>>> datetime whose __new__ has no arguments (or, more
>>> realistically, interprets its arguments differently).
>>> Instances of such a class can still be added to a timedelta.
>>> The proposal would cause this to break (since such an
>>> addition has to create a new instance, which calls __new__
>>> and __ini

Re: [Python-Dev] About multiprocessing maintainership

[Antoine Pitrou]

On Mon, 4 Feb 2019 09:45:39 -0600
Zachary Ware  wrote:
> On Mon, Feb 4, 2019 at 4:39 AM Antoine Pitrou  wrote:
> > What I did (*) is different: I asked to mark Davin inactive and to stop
> > auto-assigning him on bug tracker issues.  Davin was /still/ listed in
> > the experts list, along with me and others.  IOW, there was no "editing
> > out".  
> 
> Auto-assignment (and auto-add-to-nosy-list, for that matter) is
> handled by the "components" of the bug tracker, see
> bugs.python.org/component.  The experts list is used just for
> populating the auto-completion for the nosy-list (that is, typing
> "multi" in the nosy list entry field brings up "multiprocessing:
> davin,pitrou" currently).  Marking a dev as "(inactive)" in the
> experts list removes them from that auto-completion.

Thanks for the clarification.

In any case, here is how things usually happen.  A user files a bug
report for a certain module M.  A triager takes notice, looks up the
relevant expert(s) in the developer's guide.  If an expert is listed
with issue assignment allowed (the asterisk "*" besides the name), then
the triager assumes that expert is available and assigns the issue to
them.  If the expert with an asterisk doesn't respond to the issue,
the issue may very well get forgotten.

So it's important that experts with an asterisk are actually available
to deal with user reports.

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] [RELEASE] Python 3.8.0a1 is now available for testing

[Barry Warsaw]

On Feb 4, 2019, at 05:02, Stephane Wirtel  wrote:
> 
> Just one idea, we could create a Docker image with this alpha version.
> 
> This Docker image could be used with the CI of the main projects and the
> test suites of these projects.
> 
> If we have some issues, we should create an issue for python 3.8.0a1.

The time machine strikes again!

https://gitlab.com/python-devs/ci-images/tree/master

We call these “semi-official”!  The current image takes a slightly different 
approach, by including all the latest Python versions from 2.7, and 3.4-3.8, 
plus git head.  I just pushed an update for the latest Python 3.8 alpha and 
3.7.2.  It’s building now, but the image should be published on quay.io as soon 
as that’s done.

Contributions most welcome!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Asking for reversion

[Eric Snow]

The main problem here seems to be a shortage of communication. :/
Also, I agree on the exceptional nature of merging incomplete PRs.

-eric

On Mon, Feb 4, 2019 at 3:37 AM Łukasz Langa  wrote:
>
>
> > On 4 Feb 2019, at 01:49, Guido van Rossum  wrote:
> >
> > I think this is now up to the 3.8 release manager.
>
> I responded on the tracker: https://bugs.python.org/issue35813#msg334817
>
> I wrote:
>
> > @Davin, in what time can you fill in the missing tests and documentation?  
> > If this is something you finish do before alpha2, I'm inclined to leave the 
> > change in.
> >
> > As it stands, I missed the controversy yesterday as I was busy making my 
> > first release.  So the merge *got released* in alpha1.  I would prefer to 
> > fix the missing pieces forward instead of reverting and re-submitting which 
> > will only thrash blame and history at this point.
> >
> > FTR, I do agree with Antoine, Ronald and others that in the future such big 
> > changes should be as close to their ready state at merge time.
>
>
>
> @Raymond, would you be willing to work with Davin on finishing this work in 
> time for alpha2?
>
>
> - Ł
> ___
> 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/ericsnowcurrently%40gmail.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] Return type of datetime subclasses added to timedelta

[Guido van Rossum]

OK, I approved the PR. Can some other core dev ensure that it gets merged?
No backports though!

On Mon, Feb 4, 2019 at 8:46 AM Paul Ganssle  wrote:

> There's already a PR, actually, #10902:
> https://github.com/python/cpython/pull/10902
>
> Victor reviewed and approved it, I think before I started this thread, so
> now it's just waiting on merge.
> On 2/4/19 11:38 AM, Guido van Rossum wrote:
>
> I recommend that you submit a PR so we can get it into 3.8 alpha 2.
>
> On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle  wrote:
>
>> Hey all,
>>
>> This thread about the return type of datetime operations seems to have
>> stopped without any explicit decision - I think I responded to everyone who
>> had objections, but I think only Guido has given a +1 to whether or not we
>> should go ahead.
>>
>> Have we got agreement to go ahead with this change? Are we still
>> targeting Python 3.8 here?
>>
>> For those who don't want to dig through your old e-mails, here's the
>> archive link for this thread:
>> https://mail.python.org/pipermail/python-dev/2019-January/155984.html
>>
>> If you want to start commenting on the actual implementation, it's
>> available here (though it's pretty simple):
>> https://github.com/python/cpython/pull/10902
>>
>> Best,
>>
>> Paul
>>
>>
>> On 1/6/19 7:17 PM, Guido van Rossum wrote:
>>
>> OK, I concede your point (and indeed I only tested this on 3.6). If we
>> could break the backward compatibility for now() we presumably can break it
>> for this purpose.
>>
>> On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle  wrote:
>>
>>> I did address this in the original post - the assumption that the
>>> subclass constructor will have the same arguments as the base constructor
>>> is baked into many alternate constructors of datetime. I acknowledge that
>>> this is a breaking change, but it is a small one - anyone creating such a
>>> subclass that *cannot* handled the class being created this way would
>>> be broken in myriad ways.
>>>
>>> We have also in recent years changed several alternate constructors
>>> (including `replace`) to retain the original subclass, which by your same
>>> standard would be a breaking change. I believe there have been no
>>> complaints. In fact, between Python 3.6 and 3.7, the very example you
>>> showed broke:
>>>
>>> Python 3.6.6:
>>>
>>> >>> class D(datetime.datetime):
>>> ... def __new__(cls):
>>> ... return cls.now()
>>> ...
>>> >>> D()
>>> D(2019, 1, 6, 13, 49, 38, 842033)
>>>
>>> Python 3.7.2:
>>>
>>> >>> class D(datetime.datetime):
>>> ... def __new__(cls):
>>> ... return cls.now()
>>> ...
>>> >>> D()
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "", line 3, in __new__
>>> TypeError: __new__() takes 1 positional argument but 9 were given
>>>
>>>
>>> We haven't seen any bug reports about this sort of thing; what we *have*
>>> been getting is bug reports that subclassing datetime doesn't retain the
>>> subclass in various ways (because people *are* using datetime
>>> subclasses). This is likely to cause very little in the way of problems,
>>> but it will improve convenience for people making datetime subclasses and
>>> almost certainly performance for people using them (e.g. pendulum and
>>> arrow, which now need to take a slow pure python route in many situations
>>> to work around this problem).
>>>
>>> If we're *really* concerned with this backward compatibility breaking,
>>> we could do the equivalent of:
>>>
>>> try:
>>> return new_behavior(...)
>>> except TypeError:
>>> warnings.warn("The semantics of timedelta addition have "
>>>   "changed in a way that raises an error in "
>>>   "this subclass. Please implement __add__ "
>>>   "if you need the old behavior.", DeprecationWarning)
>>>
>>> Then after a suitable notice period drop the warning and turn it to a
>>> hard error.
>>>
>>> Best,
>>>
>>> Paul
>>> On 1/6/19 1:43 PM, Guido van Rossum wrote:
>>>
>>> I don't think datetime and builtins like int necessarily need to be
>>> aligned. But I do see a problem -- the __new__ and __init__ methods defined
>>> in the subclass (if any) should allow for being called with the same
>>> signature as the base datetime class. Currently you can have a subclass of
>>> datetime whose __new__ has no arguments (or, more realistically, interprets
>>> its arguments differently). Instances of such a class can still be added to
>>> a timedelta. The proposal would cause this to break (since such an addition
>>> has to create a new instance, which calls __new__ and __init__). Since this
>>> is a backwards incompatibility, I don't see how it can be done -- and I
>>> also don't see many use cases, so I think it's not worth pursuing further.
>>>
>>> Note that the same problem already happens with the .fromordinal() class
>>> method, though it doesn't happen with .fromdatetime() or .now():
>>>
>>> >>> class D(datetime.datetime):
>>> ...   def __new__(cls): return cls.now()
>>> ...
>>>

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

[Alexander Belopolsky]

I'll merge it tonight.

On Mon, Feb 4, 2019 at 2:22 PM Guido van Rossum  wrote:

> OK, I approved the PR. Can some other core dev ensure that it gets merged?
> No backports though!
>
> On Mon, Feb 4, 2019 at 8:46 AM Paul Ganssle  wrote:
>
>> There's already a PR, actually, #10902:
>> https://github.com/python/cpython/pull/10902
>>
>> Victor reviewed and approved it, I think before I started this thread, so
>> now it's just waiting on merge.
>> On 2/4/19 11:38 AM, Guido van Rossum wrote:
>>
>> I recommend that you submit a PR so we can get it into 3.8 alpha 2.
>>
>> On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle  wrote:
>>
>>> Hey all,
>>>
>>> This thread about the return type of datetime operations seems to have
>>> stopped without any explicit decision - I think I responded to everyone who
>>> had objections, but I think only Guido has given a +1 to whether or not we
>>> should go ahead.
>>>
>>> Have we got agreement to go ahead with this change? Are we still
>>> targeting Python 3.8 here?
>>>
>>> For those who don't want to dig through your old e-mails, here's the
>>> archive link for this thread:
>>> https://mail.python.org/pipermail/python-dev/2019-January/155984.html
>>>
>>> If you want to start commenting on the actual implementation, it's
>>> available here (though it's pretty simple):
>>> https://github.com/python/cpython/pull/10902
>>>
>>> Best,
>>>
>>> Paul
>>>
>>>
>>> On 1/6/19 7:17 PM, Guido van Rossum wrote:
>>>
>>> OK, I concede your point (and indeed I only tested this on 3.6). If we
>>> could break the backward compatibility for now() we presumably can break it
>>> for this purpose.
>>>
>>> On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle  wrote:
>>>
 I did address this in the original post - the assumption that the
 subclass constructor will have the same arguments as the base constructor
 is baked into many alternate constructors of datetime. I acknowledge that
 this is a breaking change, but it is a small one - anyone creating such a
 subclass that *cannot* handled the class being created this way would
 be broken in myriad ways.

 We have also in recent years changed several alternate constructors
 (including `replace`) to retain the original subclass, which by your same
 standard would be a breaking change. I believe there have been no
 complaints. In fact, between Python 3.6 and 3.7, the very example you
 showed broke:

 Python 3.6.6:

 >>> class D(datetime.datetime):
 ... def __new__(cls):
 ... return cls.now()
 ...
 >>> D()
 D(2019, 1, 6, 13, 49, 38, 842033)

 Python 3.7.2:

 >>> class D(datetime.datetime):
 ... def __new__(cls):
 ... return cls.now()
 ...
 >>> D()
 Traceback (most recent call last):
   File "", line 1, in 
   File "", line 3, in __new__
 TypeError: __new__() takes 1 positional argument but 9 were given


 We haven't seen any bug reports about this sort of thing; what we
 *have* been getting is bug reports that subclassing datetime doesn't
 retain the subclass in various ways (because people *are* using
 datetime subclasses). This is likely to cause very little in the way of
 problems, but it will improve convenience for people making datetime
 subclasses and almost certainly performance for people using them (e.g.
 pendulum and arrow, which now need to take a slow pure python route in many
 situations to work around this problem).

 If we're *really* concerned with this backward compatibility breaking,
 we could do the equivalent of:

 try:
 return new_behavior(...)
 except TypeError:
 warnings.warn("The semantics of timedelta addition have "
   "changed in a way that raises an error in "
   "this subclass. Please implement __add__ "
   "if you need the old behavior.", DeprecationWarning)

 Then after a suitable notice period drop the warning and turn it to a
 hard error.

 Best,

 Paul
 On 1/6/19 1:43 PM, Guido van Rossum wrote:

 I don't think datetime and builtins like int necessarily need to be
 aligned. But I do see a problem -- the __new__ and __init__ methods defined
 in the subclass (if any) should allow for being called with the same
 signature as the base datetime class. Currently you can have a subclass of
 datetime whose __new__ has no arguments (or, more realistically, interprets
 its arguments differently). Instances of such a class can still be added to
 a timedelta. The proposal would cause this to break (since such an addition
 has to create a new instance, which calls __new__ and __init__). Since this
 is a backwards incompatibility, I don't see how it can be done -- and I
 also don't see many use cases, so I think it's not worth pursuing further.

 Note that the same problem alrea

Re: [Python-Dev] Asking for reversion

[Raymond Hettinger]

> On Feb 4, 2019, at 2:36 AM, Łukasz Langa  wrote:
> 
> @Raymond, would you be willing to work with Davin on finishing this work in 
> time for alpha2?

I would be happy to help, but this is beyond my technical ability.  The people 
who are qualified to work on this have already chimed in on the discussion.  
Fortunately, I think this is a feature that everyone wants. So it just a matter 
of getting the experts on the subject to team-up and help get it done.


Raymond





___
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